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Abstract 


There  exists  a  variety  of  simulation  generation  and  analysis  products  which  have 
differing  purposes  and  functions  designed  to  simulate  a  real  military  battlefield.  Due  to  the 
particular  purpose  of  each  simulation,  it  is  impractical  to  use  one  scenario  of  a  simulation 
directly  with  another  simulation  without  a  translator  since  there  is  no  standard  scenario 
format.  In  the  current  environment,  interoperability  between  simulations  is  becoming 
more  important  in  large  scale  simulations  and  distributed  exercises.  The  Scenario  File 
Translator  (SFT)  provides  an  easy  and  accurate  way  to  create  a  scenario  from  a 
heterogeneous  simulation.  The  SFT  can  load  and  save  the  three  research  simulations: 
ModSAF,  EADSIM,  and  BATTLESIM.  It  also  defines  the  general  transitional  prototype 
(TP)  which  is  the  information  most  commonly  used  to  create  a  mock  battlefield  computer 
simulation.  System  functionality  is  accessible  through  a  graphical  user  interface  (GUI). 

The  four  top-level  steps  to  translate  a  scenario  are  loading  a  source  scenario  file,  mapping 
to  the  TP,  remapping  the  TP  to  a  transitional  target  prototype,  and  saving  the  prototype  as 
a  target  scenario  file  which  a  heterogeneous  simulation  use.  Although  this  system  was 
designed  for  three  simulations,  it  can  be  applied  to  any  other  simulations  by  creating  only 
two  additional  functions:  one  which  maps  the  new  scenario  to  the  TP  and  another  which 
remaps  the  TP  into  the  transitional  scenario  protocol. 
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THE  DEVELOPMENT 
OF  A  SCENARIO  TRANSLATOR 
FOR  DISTRIBUTED  SIMULATIONS 


1.  Introduction 


1.1  Background 

Most  people  want  maximum  results  with  minimum  investment  in  cost  and  time  when  doing  a 
work.  Attempts  to  attain  such  results  will  continue  and  computer  simulation  is  a  good  way  to 
accomplish  it.  Computer  simulation  is  very  useful  when  the  real  system  does  not  exist  or  it  is 
expensive,  time  consuming,  dangerous,  or  impossible  to  build  [Neel87].  The  effectiveness  of 
computer  simulation  in  the  military  is  especially  apparent,  since  real  combat  conditions  are 
often  costly  to  recreate  and  often  dangerous.  When  we  use  computer  simulation,  we  do  not 
have  to  fly  many  aircraft  nor  send  hundreds  of  tanks  to  attack  a  target,  furthermore  we  do  not 
have  to  maneuver  thousands  of  soldiers  to  other  places  for  training.  Computer  simulation  also 
allows  testing  of  many  scenarios  in  a  short  time  so  that  we  can  measure  which  scenario  is  the 
best  model  at  a  certain  place. 

To  simulate  a  real  battlefield,  some  preconditions  should  be  solved,  such  as  an 
accurate  terrain  database,  a  precise  description  of  strategy,  and  a  stable  network.  High  speed 
computer  networks  and  distributed  simulation  applications  make  possible  computer 
simulations  for  the  military.  Even  though  the  opposing  forces  may  be  located  far  away,  the 
high  speed  communication  network  provides  real  time  simulation  as  if  each  side  is  close  at 
hand.  Thus  the  exerciser  can  develop  fighting  skills  through  mutual  exercises.  However,  the 
important  thing  here  is  that  a  standard  communication  protocol  is  necessary  to  implement  the 
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distributed  communication.  For  example,  assume  exercise  A  uses  protocol  X  and  exercise  B 
uses  protocol  Y :  how  can  exercise  A  know  exercise  B  fires  a  missile,  or  is  fired  upon? 
Developing  a  well-defined  standard  protocol  is  as  important  as  good  simulation  software.  As 
a  result,  the  Defense  Advanced  Research  Projects  Agency  (DARPA,  now  called  ARP  A)  made 
a  standard  communication  protocol,  which  was  named  the  Simulation  Network  (SIMNET). 
Between  1983  and  1989,  ARPA  successfully  demonstrated  the  core  technology  for  networking 
large  numbers  of  manned,  homogeneous  simulators  using  SIMNET.  Distributed  Interactive 
Simulation  (DIS)  standards  are  being  developed  to  provide  industry  wide  standards  that 
enable  linking  of  heterogeneous  systems.  Since  1992,  the  DIS  standards  have  been 
demonstrated  numerous  times.  The  demonstrated  scenarios  displayed  maritime,  air-to-air, 
ground-to-air,  air-to-ground,  and  land  operations.  These  demonstrations  proved  the  viability 
of  linking  simulations  of  different  types,  based  on  different  technologies,  and  built  by  different 
organizations  [DIS  94]. 

The  past  few  years  have  seen  remarkable  advances  in  DIS.  The  DIS  environment 
allows  military  units  from  around  the  country  to  participate  in  mock  training  exercises 
without  a  large  commitment  of  resources  [Adam93].  As  mentioned  earlier,  there  now  exists  a 
variety  of  scenario  generation  and  analysis  products  such  as  Integrated  Eagle,  Janus,  CCTT 
(Close  Combat  Tactical  Trainer),  Modular  Semi-Autonomous  Forces  (ModSAF),  and 
Synthetic  Theater  of  War  (STOW).  Each  simulation  has  its  differing  purposes  and  functions. 
So  after  testing  a  scenario  with  different  simulations,  we  can  build  better  combat  models  and 
get  more  precise  verification. 

However,  a  basic  problem  still  exists.  Due  to  the  particular  purpose  of  each 
simulation,  we  cannot  use  one  scenario  of  a  simulation  directly  with  another  simulation 
without  a  translator  since  there  is  no  standard  scenario  format.  To  test  a  new  scenario,  it  is 
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impractical  to  manually  recreate  it  to  make  it  fit  another  simulation.  In  the  current 
environment,  interoperability  between  simulations  is  becoming  more  important  in  large  scale 
simulations  and  distributed  exercises.  Since  current  scenarios  can  contain  thousands  of 
entities,  scenario  setup  and  initialization  can  be  quite  laborious. 

1.2  Problem  Statement 

There  exist  several  ways  to  apply  a  battle  scenario  of  one  simulation  to  other  simulation.  The 
most  straight  forward  way  is  to  recreate  the  scenario  file  in  a  format  suitable  for  the  other 
simulation,  but  this  is  time  consuming  work  and  an  ineffective.  If  we  want  to  apply  a 
scenario  to  five  different  simulations,  we  need  to  make  five  versions  of  the  same  scenario  for 
each  simulation.  If  we  want  to  test  10  scenarios  for  these  same  five  simulations,  then  50 
completely  different  scenarios  are  needed.  There  could  be  ten  thousand  entities  in  a  scenario, 
so  it  is  not  easy  work  to  make  a  complete  scenario.  Making  manual  conversion  of  such 
scenarios  is  inefficient.  Another  solution  for  these  problems  is  a  translation  tool  to 
automatically  convert  scenarios  from  one  simulation  format  to  another.  I  propose  to  produce 
a  software  tool  that  aids  in  the  translation  of  scenario  file  formats  so  that  scenarios  developed 
by  different  simulations  can  be  run  by  each  other.  A  well-defined  translator  will  save  time 
and  money,  and  it  will  provide  the  best  way  to  test  a  scenario  with  different  simulations. 

1.3  Assumption 

Most  simulations  have  a  specific  purpose  architecture.  As  the  goal  of  each  simulation  is 
different  from  others,  the  way  to  read  or  write  a  scenario  file  may  also  be  different.  For 
example,  the  amount  of  munitions  for  a  unit  may  be  represented  in  one  simulation,  but  not 
another.  So,  translating  one  scenario  format  into  a  different  format  is  not  guaranteed  to 
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preserve  all  information.  That  means  some  data  which  is  not  present  in  a  target  simulation 
can  be  lost  while  converting  to  another  scenario.  The  important  thing  here  is  the  conversion 
rate  which  shows  how  many  entities  are  translated  to  the  other  simulation. 

1.4  Approach 

This  section  discusses  some  key  decisions  I  used  to  accomplish  this  work.  First  of  all,  I  had 
to  choose  a  conversion  method  to  translate  one  scenario  to  another.  Based  on  this  decision,  I 
designed  an  intermediate  format  covering  one  scenario  of  each  simulation.  Then  in  the 
remainder  of  the  section,  I  delineated  detailed  processes. 

1.4.1  Deterrmning  Conversion  Method  A  problem  with  writing  a  generalized  scenario 
translator  is  that  the  data  structures  used  to  initialize  scenarios  in  different  tools  are  very 
specialized.  One  way  to  solve  this  problem  is  to  develop  a  tool  which  can  map  directly 
between  any  two  simulations.  This  increases  the  conversion  rate.  This  concept  is  depicted  in 
Figure  1.1. 


Figure  1 . 1  Direct  Simulation  Conversion 


This  concept  is  efficient  when  the  number  of  simulations  is  small.  However, 
whenever  a  new  simulation  is  developed,  it  is  necessary  to  write  a  new  conversion  routine. 
This  routine  translates  the  new  scenario  of  the  new  simulation  to  each  existing  simulation;  I 
also  needed  to  create  a  routine  that  converts  a  scenario  of  an  existing  simulation  to  the  new 
simulation.  Assume  there  are  currently  N  simulations.  When  a  new  simulation  is  developed, 
N  routines  are  needed  to  map  a  scenario  of  the  new  simulator  into  the  existing  simulation,  and 
another  N  routines  are  necessary  to  map  the  scenario  of  the  existing  simulations  to  the  one  of 
the  new  simulations.  Thus  a  total  of  2*N  routines  are  needed. 

Another  way  to  do  this  is  to  do  remap  to  a  target  simulation  after  mapping  into  an 
intermediate  prototype.  This  is  more  efficient  because  it  is  not  dependent  on  the  number  of 
existing  simulations.  This  requires  two  routines:  a  routine  that  maps  to  the  intermediate 
prototype,  and  a  routine  that  remaps  to  the  target  scenario  of  the  simulation.  Thus  only  two 
routines  are  always  needed,  compared  to  the  2*N  routines  required  using  the  previous  method. 
Figure  1.2  shows  this  concept. 


Figure  1.2  Conversion  from  Simulation  to  Intermediate  Prototype 
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I  propose  that  this  translation  be  done  in  two  steps.  The  first  step  is  mapping  a 
source  scenario  to  an  intermediate  transitional  prototype.  The  second  step  is  saving  the 
intermediate  prototype  to  the  target  scenario  format  used  to  run  target  simulations, 

1.4.2  Mapping  to  Transitional  Prototype  In  order  to  develop  a  reasonable  mapping,  I  first 
began  with  a  comprehensive  survey  of  the  three  target  research  simulations:  ModSAF, 
EADSIM,  and  BATTLESIM.  Furthermore,  I  had  organized  the  survey  as  the  following  set  of 
tasks. 

•  Review  of  Semi-Automated  Forces  (SAF) 

First,  I  reviewed  the  history  of  SAF  technology  and  current  research  efforts  in  the 
field.  That  review  gave  me  a  basic  knowledge  of  the  simulations. 

•  Survey  of  current  simulations 

Next,  I  investigated  each  simulation’s  basic  architecture  and  scenario’s  formation.  It 
was  beneficial  for  me  to  understand  what  things  were  common  and  what  points  were 
unique. 

•  Finding  the  Transitional  Format 

Finding  the  transitional  format  was  the  most  important  part  of  this  research.  By 
choosing  a  well-designed  transitional  format,  I  could  make  a  more  generic  program. 
The  way  to  find  an  intermediate  transitional  prototype  that  suits  this  concept  is  either 
to  select  a  protocol  among  these  currently  developed  or  to  define  a  new  protocol 
fitting  the  above  concept.  A  more  detailed  discussion  of  this  topic  appears  in  Section 
3.3.1. 

•  Build  the  Comprehensive  Table 

Following  these  steps,  I  composed  a  table  suitable  to  compare  each  simulation.  This 
table  gave  me  the  insight  into  what  data  are  in  common  and  which  data  structure  is 
more  efficient  to  translate  a  scenario. 
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1.4.3  Remapping  to  Target  Scenario 

The  remapping  step  to  a  target  scenario  using  the  comparison  table  was  the  index  of 
performance  for  this  research  effort.  As  I  mentioned  in  Section  1.3,  it  was  unrealistic  to 
expect  100  %  conversion;  however,  a  “close”  scenario  was  likely,  and  it  was  the  goal  of  this 
research  to  determine  how  “close”  a  conversion  the  transitional  prototype  could  support.  This 
goal  was  implemented  through  the  next  two  steps. 

•  Find  the  common  data  between  target  scenario  and  the  transitional  prototype. 

•  Save  as  a  new  scenario  file  which  can  be  read  by  a  target  simulation. 


1.5  Thesis  Overview 

This  thesis  is  divided  into  six  chapters.  Chapter  Two  presents  the  background  material  on 
Advance  Distributed  Simulation,  and  DIS  and  Computer  Generated  Forces  (CGF)  or  SAFs. 
Chapter  Three  focuses  on  the  requirements  definition  and  analysis  process  and  its  translation 
into  a  system  design.  Chapter  Four  discusses  implementation  of  the  system  and  describes 
how  it  works.  Chapter  Five  summarizes  the  results  and  illustrates  several  test  cases.  Finally, 
Chapter  Six  provides  recommendations  for  future  work  and  the  conclusion. 
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IL  Backeround  and  Literature  Review 


2.1  Introduction 

This  chapter  summarizes  the  work  in  the  two  major  research  areas  that  is  relevant  to  my 
thesis  effort.  Since  the  primary  purpose  of  this  thesis  was  to  create  a  scenario  translation 
tool,  I  completed  a  survey  of  the  enabling  and  supporting  technology  in  that  field.  The  first 
section  provides  a  historical  background  how  DIS  was  evolved,  and  the  next  section  lays  the 
foundation  for  understanding  the  important  concepts  in  military  simulation.  Finally,  the  last 
section  discusses  three  of  the  simulations  recently  developed  -  ModSAF,  EADSIM  and 
BATTLESIM  -  and  focuses  on  how  each  simulation  works  and  what  are  the  differences 
among  them. 

2.2  Historical  Background 

To  date,  various  research  efforts  have  focused  on  developing  war  game  simulations  which 
have  a  particular  ability  for  the  given  research.  New  simulations  with  new  abilities  are 
created  one  after  another,  and  existing  simulations  are  upgraded  to  be  more  accurate  and 
realistic.  The  one  point  that  all  simulations  have  in  common  is  standardization  through  the 
network  for  sharing  data.  This  standardization  has  been  accomplished  using  DIS. 

DIS  had  been  started  in  1989  when  ARPA  initiated  a  program  to  enhance  the 
Simulation  Network  (SIMNET)  program.  SIMNET  was  developed  for  building  a  cross¬ 
country  network  of  interactive  combat  simulators  [Pope91].  Its  demonstration  of 
approximately  250  simulators  successfully  showed  the  possibilities  of  distributed  simulation. 
SIMNET  technology  is  still  used  today  to  train  U.S.  Army  tank  teams  around  the  country. 

DIS  is  a  set  of  protocols  that  carry  messages  about  entities  and  events  through  a 
network.  When  a  network  provides  reasonably  low  latency  (100  to  300  milliseconds)  and  low 
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latency  variance,  the  characteristics  of  the  network  present  few  problems  to  building  a  virtual 
world  that  is  separated  by  thousands  of  miles  in  the  real  world  [DIS94].  One  important 
aspect  of  DIS  development  is  the  effort  to  recognize  DIS  as  an  international  standard  for 
distributed  simulation.  Thus,  the  DIS  standard  was  submitted  and  approved  by  the  Institute 
of  Electrical  and  Electronic  Engineers  (IEEE)  as  IEEE  standard  1278.  Following  IEEE 
approval,  the  standard  was  submitted  to  the  appropriate  international  agencies  for 
international  standard  approval.  This  is  useful,  since  it  promotes  cooperation  among  the  U.S. 
and  its  allies  in  the  field  of  simulation  [McDo91]. 

2.3  Military  Simulation  Technology 

2.3.1  Distributed  Interactive  Simulation  (DIS) 

2.3. 1.1  Concept  DIS  is  an  interconnected,  time-coherent  simulation  system  which  creates  a 
distributed,  interactive  environment  using  the  IEEE  1278  protocol  [Siko95].  DIS  simulators 
exchange  information  in  formatted  messages  called  Protocol  Data  Units  (PDUs).  These  PDUs 
provide  data  for  the  management  and  control  of  a  DIS  exercise  and  provide  data  concerning 
simulated  entity  states  and  the  types  of  entity  interactions  that  take  place  in  a  DIS  exercise.  It  is 
possible  for  geographically  separated  simulators  to  interact  with  each  other  via  network 
communications  by  the  DIS  standard  [IST94].  DIS  is  designed  for  linking  the  interactive,  free  play 
activities  of  people  in  operational  exercises  to  represent  a  time  and  space  coherent  synthetic  world 
environment.  This  environment  is  created  through  real-time  exchange  of  data  units  between 
distributed,  computationally  autonomous  simulation  applications  in  the  form  of  simulation, 
simulators,  and  instrumented  equipment  interconnected  through  standard  computer  communicative 
services.  The  meaning  of  “distributed”  is  that  no  single  computer  controls  the  simulations. 

Rather,  each  local  computer  is  responsible  for  sending  local  copies  of  common  terrain  and  models 
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(e.g.,  tanks,  fighters,  and  naval  vessels),  and  remote  entities  based  on  incoming  PDU  messages. 
Local  applications  are  required  to  send  entity  updated  entity  states  when  dead-reckoning  thresholds 
are  exceeded  or  five  seconds  have  elapsed  [Gard93,  Shea92].  Entities’  positions  and  orientations 
are  predictable  by  using  the  Dead  Reckoning  algorithm  so  that  the  number  of  transmitted  PDUs 
can  be  kept  as  low  as  possible.  This  increases  the  scale  of  the  exercise  and  reduces  network 
communications  traffic  from  a  single  simulator  [Gard93].  Dead  Reckoning  is  an  important 
algorithm  as  one  of  the  basic  concepts  imderl}dng  the  DIS  architecture.  It  also  diminishes  the 
computational  processing  associated  with  receipt  of  each  new  PDU  because  fewer  PDUs  are 
received  [Harv91]. 

2.3. 1.2  DIS  Objectives  Principles  of  the  emerging  DIS  standards  and  their  applications  are 
introduced  in  this  section.  Basic  architectural  concepts  include  [IST94]: 

•  No  central  computer  controls  the  entire  simulation  exercise, 

•  Autonomous  simulation  applications  are  responsible  for  maintaining  the  state  of  one  or 
more  simulation  entities, 

•  A  standard  protocol  is  used  for  communicating  “ground  truth”  data, 

•  Changes  in  the  state  of  an  entity  are  communicated  by  simulation  applications, 

•  Perception  of  events  or  other  entities  is  determined  by  the  receiving  application,  and 

•  Dead  reckoning  algorithms  are  used  to  reduce  communications  processing. 

A  definition  of  each  of  these  concepts  is  provided  in  the  proposed  IEEE  draft  in  reference 
[IST93]. 

2.3.1.3  DIS  PDUs  DIS  currently  defines  27  different  PDUs.  A  complete  description  of  each  of 
these  PDUs  can  be  found  in  reference  [IST94]  and  can  be  grouped  into  the  following  general 
categories: 

•  Entity  Information/Interaction, 
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Warfare, 


• 

•  Logistics, 

•  Simulation  Management, 

•  Distributed  Emission  Regeneration,  and 

•  Radio  Communications. 

Only  12  of  these  27  PDUs  have  a  fixed  length.  Each  of  the  remaining  PDUs  has  a 
variable  length  dependent  upon  many  factors  including  numbers  of  articulated  parts,  numbers  and 
types  of  emitters,  length  of  audio  transmissions,  and  amount  of  data. 

Table  2. 1  [IST94]  depicts  the  entity  state  PDU  as  an  example  of  the  content  and  format  of 
the  DIS  PDUs. 

2.3.2  Advanced  Distributed  Simulation  (ADS)  Computer  simulation  has  been  used  by 
military  analysts  in  various  aspects  since  the  1950s,  especially  in  mock  battle  areas.  At  the 
beginning,  it  had  very  limited  scope  due  to  the  vastness  of  the  battle  and  the  complexity  of  the 
simulated  war,  which  also  made  it  difficult  to  use  and  to  satisfy  the  users.  The  development 
of  larger  mainframe  computers  in  the  1960s  resulted  in  enlarged  storage  capacity  and  greater 
processing  speed  allowing  better  digitized  terrain  and  larger  scenarios  than  before.  By  the 
1980s,  the  capabilities  of  computer-based  simulations  had  really  expanded  with  the  advent  of 
microprocessor  chips,  high  speed  data  communication  links,  larger  mass  storage  devices,  and 
flexible,  detailed  displays,  all  at  low  cost.  Today,  the  simulated  battlefield  can  depict  more 
accurately  real-time  war  games  because  of  continually  improving  computer  capabilities.  As 
the  SIMNET  and  DIS  demonstration  showed,  it  is  possible  to  have  different  simulated 
battlefields  at  dispersed  geographic  locations  working  together.  The  new  capabilities,  such  as 
high-speed  communication  networks,  common  network  interface/translation  devices,  and 
emerging  standard  data  protocols,  have  allowed  a  time-coherent,  interactive  synthetic 
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Table  2.1.  Entity  State  Protocol  Data  Unit 


Word 

Field 

Byte  1 

Byte  2 

Byte  3 

0 

PDU  Header 

Version 

Exer  ID 

M  1 

Family 

1 

Time 

Stamp 

2 

Length 

Pad 

3 

Entily/Force  ID 

Site 

Application 

4 

Entity 

Force  ID 

#  Artie  Parts 

5 

Type 

Kind 

Domain 

Country 

6 

Category 

Subcategory 

Specific 
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environment  where  computer  simulation,  real  equipment  and  systems,  and  humans  work 
together  in  synthetic  battlefields  for  training,  system  development,  testing,  and  force 
assessment.  This  S5mthetic  environment  through  geographically  distributed  and  using 
potentially  dissimilar  simulation  hardware  and  software  is  a  technology  area  named 
Advanced  Distributed  Simulation  (ADS)  [Siko95]. 
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There  are  many  goals  in  ADS.  The  main  goal  is  to  create  a  synthetic  world  distributed 
over  a  global  network,  which  is  realistically  populated  with:  high  resolution,  dynamic  terrain; 
tactically  significant  environmental  effects;  individual  combatants  and  weapon  platforms 
[Garr95].  Three  simulation  types  including  these  main  components  are  discussed  below.  The 
first  one  is  7/ve  simulation  ’  in  which  real  people  operate  real  systems  in  actual  operational 
conditions.  For  example,  an  operational  test  of  the  F-22  in  an  electronic  combat  environment 
in  Nevada  is  an  example  of  a  live  simulation.  The  second  one  is  'virtual  simulation  ’  in  which 
real  people  operate  simulated  systems.  An  example  is  a  testbed  such  as  Advance  Research 
Project  Agency’s  (ARP A)  Simulation  Network  (SIMNET).  However,  the  most  important  and 
capable  examples  of  this  type  are  represented  by  Distributed  Interactive  Simulation  (DIS) 
systems.  Finally,  those  simulations  in  which  simulated  people  operate  simulated  systems  are 
called  'constructive  simulations  Computer  generated  forces  such  as  Modular  Semi- 
Automated  Forces  (ModSAF)  are  good  examples  of  this  type  of  simulation. 

One  of  the  important  functions  of  ADS  is  to  ‘talk  to  and  understand’  what  other 
connected  simulations  are  doing  and  what  their  simulated  elements  are  doing.  If  the 
simulations  which  compose  a  specific  ADS  configuration  are  all  of  the  same  type,  scope,  and 
data  structure,  the  communications  interface  between  them  is  relatively  straight-forward. 
However,  most  simulations  in  an  ADS  have  different  scopes  and  data  structures.  So  a 
common  language  (or  protocol)  is  necessary  to  enable  communication  with  all  connected 
simulations.  The  most  widely  recognized  and  most  comprehensive  effort  to  define  an  ADS 
standard  simulation  protocol  is  the  DIS  protocol.  Development  of  this  protocol  occurs  as  a 
cooperative  effort  by  government  and  industry  through  Forms  called  the  Distributed 
Interactive  Simulation  Workshops  [Siko95]. 
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2.3.3  Computer  Generated  Forces  (CGF)  When  the  Army  Modeling  and  Simulation 
Master  Plan  was  published  in  1994,  it  named  20  areas  for  consideration  in  the  Army  modeling 
and  simulation  community.  The  Master  Plan  defined  the  implementing  software  standards 
across  the  modeling  community  and  encouraged  standards  for  development  through  the 
establishment  of  “teaming  arrangements”  and  “consensus  building”  within  the  Army  modeling 
community.  CGF  is  the  one  of  those  areas.  CGF  Systems  originated  in  the  SIMNET 
environment  in  the  mid  1980s.  Their  initial  use  was  to  provide  a  set  of  threat  vehicles  and 
live  friendly  forces  to  train  personnel  in  the  SIMNET  simulators.  Since  1990,  CGF  systems 
have  been  used  in  other  ways,  providing  both  friendly  and  threat  forces  in  virtual 
experimentation  environment.  These  CGF-based  virtual  battles  have  been  interfaced  with 
sensor  simulators  (J-STARS)  and  live  personnel  in  the  command  and  control  (C2)  network 
making  decisions  on  interdiction  of  deep  targets.  The  following  list  is  a  minimal  set  of 
objectives  for  any  CGF  system  as  a  “standard”  [Pick95]: 

•  The  CGF  system  must  be  useful  to  all  three  applications;  training,  advanced  technology 
demonstration,  and  analysis.  This  objective  implies  specific  requirements  such  as: 

-  Ability  for  man-in-loop  simulators  to  interface  at  any  echelon. 

-  Ability  to  interface  with  live  systems  at  any  echelon 

-  Ability  to  run  real-time  and,  for  analytic  applications,  faster  than  real-time. 

-  Ability  to  interface  with  constructive  models  in  the  constructive+virtual  environment. 

•  The  CGF  system  must  be  DIS  compatible  and  also  have  the  ability  to  operate  across  both 
local  and  wide  area  nets. 

•  The  CGF  system  must  represent  the  battle  from  Corps  to  individual  vehicle. 

•  The  CGF  system  must  interface  with  other  Service  models  in  a  Joint  exercise. 

•  The  number  of  operators  in  the  CGF  system  must  be  minimal. 

•  The  structures  and  data  bases  simulating  the  physical  and  cognitive/tactical  behaviors  of 
the  vehicles,  personnel  and  units  must  be  modular  and  easily  isolated  for  Verification, 
Validation  &  Accreditation  (W&A). 


For  the  architectural  development  of  any  CGF  system,  the  design  of  certain 
components  are  needed,  which  provide  the  simulation  with  the  ability  to  represent  the  physical 


2-7 


environment  in  which  the  battle  will  take  place,  to  represent  the  combatants  themselves  and  to 
represent  a  C2  structure  for  organizing  the  individual  combatants  into  units  and  as  a  single 
fighting  force.  The  CGF  system  also  demands  the  development  of  services  supporting  a 
distributed  simulation.  The  goals  for  depicting  a  CGF  simulated  environment  are  to  represent 
the  individual  vehicular  commander  to  perform  METT-T  (Mission,  Enemy,  Troops,  Terrain 
and  Time)  activities,  to  represent  the  effects  of  weather,  dynamic  changes  in  terrain,  and 
battlefield  haze  and  smoke. 

2.4  Distributed  Simulations 

This  section  gives  a  brief  synopsis  of  some  SAF  simulations  that  have  been  recently 
developed  such  as  ModSAF,  EADSIM  and  BATTLESIM. 

2.4.1  Modular  Semi-Automated  Forces  (ModSAF) 

ModSAF  is  the  successor  to  the  SIMNET  and  ODIN  Semi-Automated  Forces  systems. 
ModSAF  1.0  was  released  in  December  1993  following  the  development  of  the  ModSAF 
architecture  in  the  spring  of  1992  under  sponsorship  by  ARP  A/ASTRO  and  STRICOM 
[Cour95].  ModSAF  is  a  combat  simulation  that  supports  DIS.  It  lets  us  create  and  control 
combat  entities  on  a  simulated  battlefield.  These  entities  replicate  the  outward  behavior  of 
their  component  vehicle  and  weapon  systems  to  a  level  of  realism  sufficient  for  training  and 
combat  development  [ADST95].  Figure  2.1  shows  an  actual  ModSAF  simulated  battlefield. 

2.4.1.1  Mot^AF Architecture  There  are  three  eomponents  in  the  ModSAF  architecture: 

(1)  SAF station,  (2)  SAFsim,  and  (3)  Logger.  These  components  are  typically  run  on 
separate  computers  over  a  network;  however,  the  SAFsim  and  SAFstation  can  run  on 
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Figure  2.1.  ModSAF  simulated  battlefield 


the  same  computer.  The  components  communicate  physical  battlefield  state  and  events 
among  themselves  through  the  simulation  (DIS)  protocol  and  command,  control,  and  system 
information  through  the  Persistent  Object  (PO)  protocol  [ADST95]. 

Figure  2.2  shows  the  SAFstation  and  SAFsim  components  communicating  over  a 
network  via  PO  and  simulation  packets  that  are  marked  with  the  same  exercise  ID  [ADST95]. 
SAFsim  and  SAFstation  communicate  command,  control,  and  system  information  via  PO 
packets  for  bundling  graphic,  unit,  model  parameter,  task,  task  frame,  and  exercise  data. 
When  we  create  objects  on  the  SAFstation,  PO  packets  which  are  representing  the  state  of 
each  object  are  projected  onto  the  network  so  that  the  objects  they  represent  can  be  simulated 
by  the  SAFsim.  SAFsim  and  SAFstation  communicate  physical  battlefield  state  and  events 
between  themselves  via  simulation  packets  for  entity  state,  impact,  collision,  fire, 
initialization,  radar,  and  weather  data  [ADST95]. 
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Figure  2.2  SAFstation  and  SAFsim  components  of  ModSAF 


The  Parameter  Database  contains  the  modeling  parameters  used  in  the  construction  of 
the  ModSAF  system.  This  set  of  parameter  files  allows  modification  of  the  ModSAF  system 
without  further  computer  programming.  Both  the  SAFstation  and  the  SAFsim  components 
have  access  to  a  Terrain  Database.  The  SAFsim  simulates  objects  known  as  ModSAF 
‘entities’  (such  as  planes  and  tanks)  which  can  behave  autonomously.  When  a  SAFsim 
simulates  a  unit,  the  SAFsim  not  only  creates  the  entities  in  the  unit,  it  also  builds  a  structure 
corresponding  to  the  unit  hierarchy. 

2.4. 1.2  Scenario  File  organization  ModSAF  uses  only  one  file  to  present  a  battle  scenario 
that  might  have  hundreds  or  thousands  of  entities.  ModSAF  2.1  defines  21  classes  to  describe 
these  entities.  A  scenario  file  consists  of  two  parts;  a  header  part  and  an  entity  part.  The 
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header  part  includes  some  global  data  such  as  version  number,  number  of  objects  and  number 
of  entries.  The  rest  of  a  scenario  file  is  all  about  these  entries.  ModSAF  reads  a  scenario  file 
sequentially  according  to  this  number  of  entries.  An  entity  part  also  consists  of  two  parts:  the 
file  entry  part  and  the  class  part.  The  important  data  of  the  file  entry  part  is  the  size  of  class 
which  follows  the  entry  part.  Table  2.2  shows  this  data  structure  of  a  scenario  file.  As  each 
class  from  the  scenario  file  is  read,  one  large  battle  scenario  is  created. 


Table  2.2  Data  Structure  of  ModSAF  scenario  file 


Name 

Data  of  Interest 

Header  Part 

File  Format 

Protocol  Version 

Database  Version 

Number  of  Objects 

Number  of  Entities 

0 

File  Entry 

Serial  Number 

Variant  Size 

Class 

1 

File  Entry 

Class 

continue  by  number 

of  objects  in  header  part 

2.4.2  Extended  Air  Defense  Simulation  (EADSIM) 

EADSIM  is  a  simulation  of  air  and  missile  warfare  used  for  scenarios  ranging  from  few-on- 
few  to  many-on-many.  Each  platform  (such  as  a  fighter  aircraft)  is  individually  modeled  and 
the  interaction  among  the  platforms  is  also  individually  modeled.  EADSIM  also  models  the 
Command  and  Control  (C2)  decision  processes  and  the  communications  among  the  platforms 
on  a  message-by-message  basis.  Intelligence  gathering  is  explicitly  modeled  as  is  the 
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intelligence  information  used  in  both  offensive  and  defensive  operations  [TBE95].  The 
general  areas  modeled  are:  air  defense,  offensive  air  operations,  attack  operations,  multi-stage 
ballistic  missiles,  air  breathers,  sensors,  jammers,  satellites,  early  warning,  generic 
noncombatants,  communications,  electronic  warfare,  terrain,  weaponry,  and  areas  of  interest. 
Figure  2.3  depicts  an  EADSIM  Scenario  playback. 


3U  Map 


Figure  2.3  EADSIM  Scenario  Playback 


2.4.2. 1  EADSIM  Architecture  The  EADSIM  model  consists  of  numerous  processes  and 
process  applications  which  perform  three  basic  functions:  simulation  setup,  execution  of  a 
scenario,  and  post-processing  and  analysis.  The  simulation  setup  and  post-processing  and 
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analysis  tools  are  run  on  a  graphic  window  manager  which  provides  the  primary  user 
interface.  The  execution  of  a  scenario  is  performed  by  a  set  of  run-time  models  running  in  a 
multi-process  configuration.  Figure  2.4  shows  the  processes  and  applications  making  up  each 
of  these  areas  [TBE95]. 
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Figure  2.4  EADSIM  Model  Processes  and  Applications 


2.4.2.2  Scenario  File  Organization  A  scenario  file  is  made  by  EADSIM’s  Scenario 
Generation.  The  data  of  the  scenario  is  organized  in  a  hierarchical  structure  on  which  each 
level  of  the  hierarchy  is  built  on  lower  levels.  The  lowest  level  in  the  hierarchy  is  the 
elements.  Combinations  of  these  individual  component  elements  are  then  used  to  organize 
System  Elements  that  are  deployed  to  form  Platforms.  Groupings  of  Platforms  are  built  into 
Laydowns,  where  the  Platforms  in  the  Laydowns  are  interconnected  with  Networks  which  also 
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use  the  Protocol  elements.  This  Platform  level  corresponds  to  entities  which  most  people 
know.  Areas  of  Interest  (AOIs)  can  be  created  and  associated  with  both  Platforms  and 
Networks.  The  Map  specification  forms  the  geographic  basis  for  the  scenario.  The  scenario 
is  then  a  further  combination  of  all  of  the  lower  level  data  [TBE95].  Figure  2.5  [TBE95]  is  a 
diagram  representing  the  data  organization. 


Figure  2.5  EADSIM  Scenario  Composition 


2.4.3  Battlefield  Simulation  (BATTLESIM) 

BATTLESIM  is  one  of  the  Air  Force  Institute  of  Technology  (AFIT)  Parallel  Discrete  Event 
Simulation  (PDES)  research  efforts.  The  primary  discrete  event  simulation  (DES) 
environments  available  for  use  at  AFIT  are  Battlefield  Simulation  (BATTLESIM),  the 
Parallel  Ada  Simulation  Environment  (PASE),  Very  High  Speed  Integrated  Circuit  (VHSIC) 
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Hardware  Description  Language  (VHDL)  Simulation  (VSIM),  and  Queuing  Model 
Simulation  (QUEUESIM).  These  environments  have  evolved  over  the  course  of  the  AFIT 
parallel  simulation  research  program  to  employ  parallelism  using  the  Chandy-Misra 
conservative  synchronization  approach  as  implemented  in  the  SPECTRUM  (Simulation 
Protocol  Evaluation  Testbed  using  Reusable  Models)  host  manager  [Hill94].  DES  is  an 
event-driven  simulation  approach  in  which  the  simulation  changes  state  upon  event  execution 
[Hill94].  PDES  is  usually  viewed  as  the  decomposition  of  a  single  DES  program  into  logical 
units  that  can  be  executed  concurrently  on  distributed  processing  architectures  [Fuji93]. 
BATTLESIM  is  integrated  with  TCHSIM  (Thomas  C  Hartrum  Simulation)  which  is  a 
collection  of  general  DES  mechanisms  and  services  and  with  SPECTRUM  which  is  a  parallel 
simulation  protocol  testbed  based  on  the  LP  (Logical  Process)  model. 

2.4.3.1  BATTLESIM  Architecture  BATTLESIM  is  a  battlefield  simulation  PDES 
application  supported  by  some  lower-level  components.  Figure  2.6  [Hill94]  shows  the  major 
BATTLESIM,  TCHSIM,  and  SPECTRUM  components  in  the  context  of  the  general  DES 
architecture.  The  lowest  level  in  the  component  is  the  AFIT  version  of  SPECTRUM  that 
provides  the  host  machine  process  management  and  communication  services.  The 
SPECTRUM  supports  the  TCHSIM  as  it  manages  the  creation  and  communication  between 
each  LP.  The  processing  which  supports  TCHSIM  contains  both  an  input/output  message 
handler  and  synchronization  logic  for  inter-LP  message  flow  control.  TCHSIM  is  an  object- 
oriented  collection  of  structures  and  operations  that  provide  basic  simulation  services.  It  also 
is  simulation  kernel,  providing  a  simulation  clock,  a  NEQ  (Next  Event  Queue),  a  top-level 
event  dispatcher,  and  structural  definitions  for  simulation  events  and  relationship  mappings 
[Hill94]. 
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BATTLESIM 
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Figure  2.6  BATTLESIM,  TCHSIM,  and  SPECTRUM 


2.4.3.2  Scenario  File  Organization  A  scenario  file  of  BATTLESIM  generally  consists  of 
two  parts.  The  first  part  is  a  Header  part  which  declares  global  data  for  the  scenario  file. 

The  second  part  is  the  Entity  part  that  can  be  repeated  many  times.  Table  2.3  shows  the 
organization  of  a  scenario  file.  In  the  Entity  part,  there  are  several  other  repeated  Entity 
parts,  as  many  as  defined  by  the  number  of  each  part. 
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Table  2.3  BATTLESIM  Input  File 


1  Name 

Detailed  Contents 

Version  Number 

Terrain 

File  Name 

Minimum,  Maximum  Coordinates 

Sector 

Number  of  Sectors 

Describing  Sectors  (can  be  repeated) 

Icon 

Number  of  Icons 

Describing  Icons  (can  be  repeated) 

Object 

Type,  ID,  Location,  Velocity, 

Orientation,  Limitations 

Entity 

Part 

Route 

Number  of  Route  Points 

Describing  Route  Points  (can  be  repeated) 

Sensors 

Number  of  Sensors 

Describing  Sensors  (can  be  repeated) 

Armaments 

Number  of  Armaments 

Describing  Armaments  (can  be  repeated) 

Targets 

Number  of  Targets 

Describing  Targets  (can  be  repeated) 

Defensive 

System 

Number  of  Defensive  Systems 

Describing  Defensive  Systems(can  be  repeated) 

2.5  Summary 

This  chapter  discussed  the  background  on  Distributed  Interactive  Simulation  (DIS) 
and  a  new  technology  area.  Advance  Distributed  Simulation  (ADS),  as  well  as  Computer 
Generated  Forces.  It  also  provided  a  brief  synopses  of  some  SAF  simulations  which  were 
recently  developed  and  available  for  experimentation  at  AFIT.  Specifically,  this  chapter 
addressed  how  each  simulation  works  and  what  are  the  differences  among  them.  It  is 
important  to  first  understand  the  architecture  of  each  simulation  and  the  organization  of  their 
scenario  files  before  we  can  design  a  process  for  translating  between  these  formats. 
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III.  System  Requirements  and  Deshn 


3.1  Introduction 

This  chapter  describes  the  requirements  for  the  Scenario  Translator  and  their  incorporation 
into  the  system  design.  I  specified  the  definition  of  several  essential  words  in  my  thesis  work 
area,  and  delineated  General  objectives  of  the  system  design  in  the  requirements  section. 
Design  details  follow  in  the  design  section.  General  requirements  are  introduced  in  the 
discussion  of  the  definition  phase.  The  overall  requirements  formed  the  basis  for  system 
design,  while  the  detailed  requirements  translated  into  specific  system  capabilities. 


3.2  Definitions 

We  use  the  following  definitions  throughout  this  document  as  shown  below: 

•  Simulation;  a  method  for  implementing  a  model  over  time 

•  Scenario:  a  sequence  of  events  or  a  possible  course  of  action 

•  Scenario  File:  a  file  which  stores  a  scenario 

•  Source  Scenario:  a  scenario  file  which  will  be  translated  to  another  format 

•  Target  Scenario:  a  scenario  file  which  is  produced  by  a  translation  tool 

•  Source  Simulation;  a  computer  simulation  which  operates  a  source  scenario 

•  Target  Simulation;  a  computer  simulation  which  operates  a  target  scenario 

•  Transitional  Prototype  (TP);  an  intermediate  prototype  to  translate  a  source  scenario  to  a  target 
scenario 

•  Transitional  Source  Scenario  Prototype:  a  data  stmcture  in  computer  memory  which  stores  a  source 
scenario 

•  Transitional  Target  Scenario  Prototype:  a  data  stmcture  in  computer  memory  which  stores  a  target 
scenario 

•  Scenario  File  Translator  (SFT);  a  translation  program  that  converts  a  source  scenario  to  a  target 
scenario 
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3.3  Requirements 

The  requirements  are  divided  into  five  main  areas; 

•  Defining  a  Transitional  Prototype, 

•  Loading  a  source  scenario  of  a  source  simulation 

•  Mapping  the  source  scenario  to  the  TP, 

•  Remapping  the  TP  to  a  transitional  target  scenario  prototype,  and 

•  Saving  the  transitional  target  scenario  prototype  as  a  target  scenario  for  a  target 
simulation. 

The  first  requirement,  defining  a  TP,  is  the  most  important  part  of  my  work  because  a  good 
prototype  can  accommodate  common  simulations.  This  makes  the  system  extensible  and 
reusable.  The  second  requirement,  loading  a  source  scenario  of  a  source  simulation,  stems 
from  the  necessity  to  convert  a  battle  scenario  to  one  which  can  be  run  by  another  simulation. 
The  third  goal,  mapping  the  source  scenario  to  the  TP,  is  also  important  since  it  determines 
how  much  information  can  be  translated  from  the  original  battle  scenario  to  another 
simulation.  Fourth,  remapping  the  TP  to  a  transitional  target  scenario  prototype  is  a 
necessary  step  to  convert  a  source  scenario  to  a  target  scenario.  Finally,  saving  a  transitional 
target  scenario  prototype  is  significant  since  all  my  effort  is  worthless  if  the  target  simulation 
cannot  read  the  target  scenario  and  work  fine. 

3.3.1  Defining  a  Transitional  Prototype 

3.3. 1.1  Insufficiency  of  DIS  PDU  As  mentioned  previously,  creating  a  well-defined 
prototype  is  the  most  important  part  of  this  work.  Initially,  it  was  desired  to  select  a  widely- 
used  prototype.  Such  a  selection  would  provide  better  accuracy  in  translating  simulation 
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scenarios  as  well  as  save  time  by  precluding  the  necessity  of  defining  a  new  prototype.  For 
these  reasons,  it  was  decided  to  use  DIS  PDUs  to  define  the  TP,  since  most  simulations  either 
support  or  will  support  that  protocol.  DIS  PDUs  send  current  events  over  the  network,  so 
other  heterogeneous  simulations  can  reorganize  the  scenario  by  receiving  these  PDUs.  It  also 
provides  for  the  simulation  to  predict  the  direction  of  an  entity  by  using  the  dead  reckoning 
algorithms.  Unfortunately,  DIS  PDUs  do  not  provide  certain  critical  pieces  of  information 
including  the  first  position  of  an  entity,  amount  of  munitions,  mission,  etc.  Thus,  although  it 
is  possible  to  ascertain  where  an  entity  is  going,  it  is  not  possible  to  determine  where  it  came 
from,  why  it  is  on  its  current  heading,  or  what  its  actions  will  be  when  it  arrives  at  its 
objective.  Table  3.1  provides  comparison  between  the  type  of  information  which  each 
simulation  has  and  its  matching  data  in  DIS  PDUs. 


Table  3.1  Matching  Comparison  between  Simulation  Scenarios  and  DIS 


Simulation 

Name 

Number  of  Variables 

DIS  Matching 
Number 

Percentage 

Header 

Entity 

Subtotal 

ModSAF 

11 

271 

282 

17 

6.0 

EADSIM 

167 

215 

382 

13 

3,4 

BATTLESIM 

15 

51 

66 

17 

25.8 

Total 

193 

537 

730 

47 

6.4 

3.3. 1.2  Defining  a  New  Prototype  The  previously-mentioned  limitations  of  DIS  PDUs 
required  defining  a  new  prototype  which  contains  the  static  and  scenario-wide  information 
missing  in  the  DIS  PDUs.  In  order  to  develop  a  new  prototype,  it  is  first  necessary  to  define 
those  piece  of  information  which  form  the  basic  scenario.  First  of  all,  the  scenario  entity  and 
the  mission  to  be  performed  by  the  entity  are  the  basic  compositions  of  a  scenario.  There  are 
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thousands  of  different  entity  types.  For  example,  an  entity  can  be  defined  as  a  platoon  or  as 
ten  army  divisions.  It  could  be  something  as  small  as  an  anti-personnel  mine  or  as  large  as  an 
airplane,  tank,  missile  base,  or  aircraft  carrier.  An  entity  also  has  its  own  initial  position, 
mission,  armed  capacity,  orientation  and  velocity  as  well  as  entity  ID  and  entity  name.  Items 
such  as  entity  ID  are  especially  important  because  they  allow  for  unique  identification.  The 
capacity  of  their  armament  is  also  quite  different,  just  as  the  amount  and  kind  of  munitions 
that  can  be  loaded  on  an  F- 16  may  vary.  However,  the  entities  themselves  do  not  comprise 
the  entire  scenario.  Only  after  each  entity  is  given  a  mission  is  a  scenario  brought  to  life. 
Missions  also  depend  on  the  types  of  entities.  Missions  for  ground  units  are  quite  different 
than  those  for  air  units.  Thus,  both  entity  and  mission  must  be  described  when  defining  a  new 
prototype.  Furthermore,  the  effect  of  the  environment  cannot  be  neglected  in  composing  a 
scenario.  Mountains,  buildings  and  weather  conditions  must  be  considered  since  both  sides 
are  not  fighting  on  a  plain  where  everybody  can  see  each  other  directly.  Finally,  not-readily- 
quantifiable  items  such  as  willingness  to  fight,  morale,  and  experience  can  also  affect  a 
scenario’s  outcome  and  are  worth  consideration.  A  more  detailed  discussion  of  this  topic 
appears  in  Section  3.3.3,  Transitional  File  Specification. 

3.3.2  Loading  a  Source  Scenario  The  first  step  to  convert  one  battle  scenario  to  another  is 
to  read  the  source  scenario.  This  is  accomplished  in  most  simulations  via  embedded 
procedures.  Since  the  objective  of  this  work  was  to  develop  a  translator  program,  it  was 
necessary  to  separate  the  scenario  initialization  code  that  simply  reads  the  source  scenario. 

This  has  the  benefit  of  greatly  simplifying  the  SFT’s  reader.  It  is  reasonable  that  the  resulting 
data  by  the  loading  system  should  be  same  as  the  one  by  a  distributed  simulation.  In  chapter 
Four,  Implementation,  I  discuss  advantages  and  disadvantages  with  using  the  source 
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simulation’s  reading  module  directly  or  creating  a  new  simple  reading  module  to  load  a 
scenario. 

3.3.3  Mapping  to  a  Transitional  Prototype  As  described  in  Section  1.3,  using  the 
intermediate  format  is  efficient  because  it  is  not  dependent  on  the  number  of  existing 
simulations.  As  we  can  see  in  Figure  3.1,  only  two  routines  are  needed  even  when  a  new 
simulation  is  developed. 


Figure  3.1  Conversion  using  an  Intermediate  Format 

Matching  each  simulation  to  the  TP  guarantees  greater  extensibility  than  a  direct  matr.hinp  of 
each  simulation  to  one  another  as  mentioned  in  Section  1 .4,  Approach.  When  converting  to 
the  TP,  it  is  important  that  the  mapping  should  be  performed  to  the  most  general  and 
acceptable  data  which  can  be  remapped  to  any  simulation.  The  position  of  an  entity  is  a  good 
example.  The  position  of  an  entity  can  vary  between  simulations,  because  of  terrain 
differences  and  relative  coordinates  used  by  each  simulation.  If  the  coordinates  of  the  entity 
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are  saved  as  they  are  when  mapping  to  the  TP,  it  may  cause  confusion  in  other  simulations. 
Additionally,  unless  the  defined  TP  covers  all  of  the  information  contained  in  a  source 
scenario,  parts  of  the  scenario  may  become  lost. 


For  example,  there  are  two  simulations,  each  of  which  has  a  different  purpose. 
Denoting  the  scenario  files  associated  with  each  simulation  as  SI  and  S2,  respectively,  we 
want  to  translate  SI  to  S2.  SI  is  therefore  a  source  scenario  while  S2  is  a  target  scenario. 
After  mapping  SI  to  the  TP,  the  mapped  area  is  shown  by  1 


in  Figure  3.2.  This  results  in 


the  area  shown  as  ^  becoming  lost.  When  we  define  the  more  general  intermediate 
prototype,  the  mapped  area  ( ^  area)  becomes  larger  and  the  lost  data  area)  becomes 


smaller. 


3.3.4  Remapping  to  a  Transitional  Target  Scenario  Prototype  After  mapping  a  source 
scenario  to  the  intermediate  format,  TP,  it  is  ready  to  be  subsequently  changed  to  any  format. 
When  we  wanted  to  change  scenario  SI  to  scenario  S2  in  the  previous  example,  it  was 
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necessary  to  convert  the  mapped  area  to  a  writable  structure  to  save  as  scenario  S2,  in  other 
words,  to  map  the  common  area  between  SI  and  TP  to  a  common  area  between  TP  and  S2. 
In  the  mapped  area  in  the  previous  example,  the  part  which  is  common  between  the 
intermediate  format  and  S2  is  the  area  shown  as  111111111  in  the  Figure  3.3. 


Figure  3.3  Common  Area  Between  Intermediate  Format  and  Target  Scenario 

Of  prime  importance  in  the  file  creation  is  to  consider  data  which  is  defined  in  the 
TP,  but  cannot  be  re-mapped  to  the  target  scenario.  In  most  cases,  this  data  affects  the  other 
scenario  in  a  limited  manner  since  this  area  is  information  for  only  the  target  scenario  such  as 
host  computer  name,  directory  path,  set-up  data  for  background  color,  image  type,  and  entity 
icon  format.  Thus,  the  loss  of  the  most  data  in  this  area  is  acceptable.  However,  there  still 
exists  some  critical  data  of  a  target  scenario  which  is  not  represented  in  the  source  scenario. 
This  results  in  lost  data  ( ^  area  in  Figure  3.4).  The  problem  of  undefined  can  be  mitigated 
by  mapping  to  commonly  used  default  values.  For  example,  assume  a  scenario  needs  the 
angle  of  the  radar  beam  of  an  aircraft,  but  that  information  is  not  available.  In  this  instance. 
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that  information  can  be  replaced  by  the  common  average  angle  of  the  radar  beam,  a  value 
which  is  commonly  known  and  can  be  readily  approximated. 


3.3.5  Saving  the  Transitional  Target  Scenario  Prototype  After  mapping  the  intermediate 
format,  TP,  to  a  transitional  target  scenario  prototype,  a  new  scenario  file  is  created.  The 
newly  saved  scenario  file  should  be  readable  by  the  target  simulation.  Here  we  also  must 
determine  whether  to  use  an  existing  output  module  within  the  target  simulation’s  code  or  to 
develop  a  new  module.  Chapter  Four  discusses  this  issue  in  more  detail. 

3.4  Design 

3.4.1  Hardware  Specification  I  designed  this  program  to  be  machine  independent. 
Platforms  used  in  testing  were  the  SGI  and  Sun  Workstations. 
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3.4.2  Software  Specification 

3.4.2. 1  General  Organization  Figure  3.5  shows  the  general  organization  and  operation 
process  of  this  program.  The  Translator,  the  core  of  this  program,  loads  the  source  scenario 
to  be  translated,  maps  to  the  TP,  and  then  saves  as  a  target  scenario.  The  TP  can  either  be 
stored  to  disk  for  future  use  or  immediately  converted  to  another  target  scenario. 


3.4.2.2  User  Interface  I  designed  a  Graphics  User  Interface  (GUI)  using  the  Motif  library 
to  provide  a  convenient  interface  for  the  user.  In  the  instance  where  the  Motif  library  is  not 
available  on  the  machine  of  implementation,  I  also  made  the  program  with  a  command  line 
interface. 
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3.4.2.3  Object  Diagram  The  Figure  3.6  shows  the  object  diagram  of  the  Scenario  File 
Translator.  This  top-level  diagram  also  shows  the  unique  object  classes  identified  for  the 
SFT  based  on  the  decomposition  of  system  requirements.  The  seven  objects  within  the  SFT 
are:  the  Translator  object,  the  Scenario  File  object,  the  Prototype  object,  the  Transitional  File 
object,  the  Entity  object,  the  Character  object,  and  the  Mission  object.  The  Simulation  object 
is  composed  of  the  Scenario  File  object,  the  Terrain  object,  and  the  Initial  Setting  object. 

Since  the  SFT  only  interfaces  with  the  Scenario  File  object,  only  this  object  is  important  to 
my  design.  The  Scenario  File  object  consists  of  the  Entity  objects,  which  have  their  own 
characters  and  missions  as  mentioned  in  Section  3.2. 1.2,  Defining  a  New  Transitional 
Prototype. 

The  Translator  object  contains  the  Prototype  and  Transitional  File  objects  and  uses 
the  Scenario  File  object  to  load  and  save  the  TP.  To  map  from  the  source  scenario  to  a  target 
scenario,  the  Translator  object  loads  into  memory  each  simulation  transitional  format.  The 
reason  why  the  transitional  scenario  prototype  is  needed  is  discussed  in  Section  3.4.4, 
Transitional  Target  Scenario  Prototype.  After  the  Translator  loads  the  source  scenario,  it 
maps  the  scenario  to  the  Prototype  object.  The  Translator  can  save  the  scenario  as  either  the 
target  scenario  or  the  Transitional  File  format. 

To  save  to  the  target  scenario,  two  steps  are  needed.  The  first  step  is  to  map  the  TP 
to  the  transitional  target  scenario  prototype,  then  the  Translator  program  saves  the  TP  as  a 
target  scenario,  which  the  target  simulation  can  then  use. 
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Figure  3.6  Scenario  Translator  Object  Diagram 

3. 4. 3  Transitional  Prototype  Requirements 

3.4.3. 1  Ideal  Prototype  The  ideal  format  for  the  TP  is  a  set  of  information  which  covers  all 
data  for  all  simulations  including  those  which  are  not  currently  supported  by  the  translator. 
Clearly,  this  is  not  practical;  therefore,  including  parts  generally  common  to  all  simulation 
scenarios  is  advisable. 

3.4. 3.2  Proposed  Prototype  The  basic  essential  composition  of  a  scenario,  the 
characteristics  and  missions  of  the  entities,  have  to  be  describable  in  any  format  I  propose. 
Extensibility  of  the  translator  is  promoted  when  the  way  to  address  the  entity  and  mission  is 
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accomplished  through  general  methods.  Figure  3.7  shows  the  relationship  among  ModSAF, 
EADSIM,  BATTLESIM,  and  the  TP. 


The  overlapping  parts  in  the  Figure  3.7  indicate  the  common  parts  between  any  two 
simulations.  The  size  of  each  rhombus  and  a  circle  in  the  figure  does  not  present  the  actual 
file  size  of  each  scenario  and  the  intermediate  format,  respectively.  The  center  part  where  the 
three  rhombuses  overlap  is  the  most  common  information  which  is  present  in  all  three 
simulations.  As  is  evident  in  the  figure,  some  data  can  be  lost  in  mapping  from  a  scenario 
into  the  TP.  In  this  case  the  default  values  should  be  matched  to  the  undefined  part  in  the  TP 
during  mapping  from  the  TP  to  a  target  scenario.  How  I  accomplished  this  is  discussed  in  the 
following  section. 
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3. 4. 4  Transitional  Scenario  Prototype  Specification 

When  loading  a  source  scenario,  it  is  desirable  to  read  all  information  contained  in  the  using 
source  simulation’s  original  data  structures.  Thus  the  transitional  source  scenario  prototype 
are  designed  to  read  all  information  whether  needed  by  another  simulation  or  not  to  minimize 
data  loss.  The  rest  of  this  section  describes  the  data  structure  of  the  source  scenarios  and 
tells  how  these  structures  influenced  the  design  of  the  transitional  data  structure.  The  reader 
may  refer  to  Appendix  A  for  more  details  about  each  transitional  source  scenario  prototype. 

3.4.4.1  ModSAF  As  mentioned  in  section  2.4.1.2,  a  ModSAF  scenario  file  is  divided  into 
two  sections:  a  Header  part  and  a  Class  part.  Figure  3.8  illustrates  the  top-level  data 
structure  of  a  ModSAF  scenario  file. 

Transitional  ModSAF  Scenario  Prototype 

Pointer  to  Header  Part 
Array  Pointer  to  File  Entry 
Array  Pointer  to  Class  part 

Figure  3.8  Transitional  ModSAF  Scenario  Prototype 

3.4.4.2  EADSIM  It  is  not  possible  to  create  a  scenario  by  reading  only  one  file  in  EADSIM 
because  a  complete  scenario  is  contained  in  several  different  files.  The  important  files  among 
them  are  the  laydown  file  which  stores  the  platforms  describing  each  entity,  and  the  scenario 
file  which  describes  the  initial  conditions  and  the  name  of  laydowns.  Figure  3.9,  Figure  3.10 
and  Figure  3.11  shows  the  Prototypes  for  a  ‘scenario  file’,  a  ‘laydown  file’,  and  a  platform. 
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Transitional  EADSIM  ‘Scenario  File  ’  Prototype 

Structure  of  Header 
Pointer  to  Laydown  File  Name 
Structure  of  Element  Map 
Pointer  to  Network  File 
Structure  of  Zero  thru  Max  Host 
Structure  of  Unused  String 
Structure  of  Debug 
Structure  of  Host 

Structure  of  Max  File  thru  C3I  Output 

Structure  of  Truth 

Structure  of  SPDS 

Structure  of  Log 

Structure  of  Statistics 

Structure  of  Probability  Statics 

Structure  of  File 

Structure  of  Earth  Rad 

Structure  ofHzulu 

Structure  of  Display  thru  Route 

Structure  of  Format  thru  Starting 

Structure  of  Processing 

Structure  of  Write 

Structure  of  C3I  Log 

Structure  of  Image 

Structure  of  Trans  Rad  File  Path 

Structure  of  Time 

Structure  of  External 

Structure  of  TEA 

Figure  3.9  Transitional  EADSIM  ‘Scenario  File’  Prototype 


Transitional  EADSIM  Laydown  File  ’  Prototype 

Version  Number 
Number  of  Platforms 
Pointer  to  Platform 

Figure  3.10  Transitional  EADSIM  ‘Laydown  File’  Prototype 
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Transitional  EADSIM Platform  Prototype 


Military  ID 
System  ID 
Commander  ID 
Color  Index 
Pointer  to  Sensor 

Number  of  Communicaitons  Devices 

Pointer  to  Com  Dev 

Pointer  to  Jammer 

Number  of  Assests 

Pointer  to  Asset 

Number  of  Targets 

Pointer  to  Target 

Number  ofIFTU  Platforms 

Pointer  to  IFTU  Platform 

Boolean  of  Sim,  Hhour,  Local,  Zulu,  HM  No  Delim,  HMS,  As  Entered 
String  of  Time  Suffix 

Boolean  of  Log  Track  Event,  Laser  Absolute,  Laser  Rest  Az,  laser  Rest  El 

Platform  Type 

Structure  of  Satellite 

Boolean  of  Use  Route  Data 

Pointer  to  Use  Route  Data 

Pointer  to  Not  Use  Route  Data 

Number  of  PTLs 

Pointer  to  PTL 

Number  of  LCS 

Pointer  to  LCS 

Number  of  Decoys 

Pointer  to  Decoys 

Number  of  Surv  Platform 

Pointer  to  Surv  Platform 

Boolean  of  CMData,  EM  Com  Default,  EM  Con  Authority 
Pointer  to  Aircraft 
Pointer  to  Airbase 

Figure  3.11  Transitional  EADSIM  Platform  Prototype 


3.4.4.3  BATTLESIM  It  is  sufficient  to  read  one  file  for  loading  a  BATTLESIM  scenario. 
Figure  3.12  depicts  the  Prototype  for  a  BATTLESIM  scenario. 
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Transitional  BATTLESIM  Prototype 


Object  Type 
Object  ID 
Current  Time 
Update  Origin 
Number  of  Events 
Structure  of  Location 
Structure  of  Velocity 
Structure  of  Orientation 
Structure  of  Rotation 
Player  Size 
Mass 

Pointer  to  Polygon  List 
Pointer  to  Subclass 

Figure  3.12  Transitional  BATTLESIM  Prototype 


3. 4.4.4  Transitional  Prototype  Table  3.2  shows  a  data  structure  of  the  TP.  Each  structure 
consists  of  variables  that  have  same  character.  The  column  ‘Type’  describes  the  variable 
format  of  the  structure,  and  the  enumeration  type  is  described  in  Appendix  B.  The  variable 
name  ‘Number  of  Entities’  indicates  how  many  entities  are  contained  in  the  transitional  file. 
The  remainder  of  the  file  contains  specific  information  about  each  entity.  The  entity  field 
structure  consists  of  nine  subfields:  Entity  Header,  Entity  Type,  Entity  Location,  Entity 
Velocity,  Entity  Orientation,  Munitions,  Sensor,  Jammer,  and  Task  field.  Each  entity  is 
uniquely  identified  by  the  number  contained  in  the  Entity  Header  field.  The  Entity  ID  should 
be  unique  in  a  scenario.  The  Force  ID  in  the  Entity  Header  structure  indicates  whether  the 
entity  is  a  friendly  or  enemy  force. 

If  the  entity  has  a  name,  the  Entity  Name  field  in  the  Entity  Header  stores  it.  The 
Entity  Type  Structure  shows  the  kind  of  the  entity.  It  follows  the  DIS  standard  as  specified  in 
the  document.  Enumeration  and  Bit-encoded  Values  for  use  with  IEEE  1278.1-1994, 
Distributed  Interactive  Simulation  -  Application  Protocols  [IST94-1].  I  designed  for 
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Table  3.2  Data  Stracture  of  Transitional  File 


Name 


Stracture  Name 


Number  of  Entities 


Entity  Header 


Variable  Name 


Entity  Type 


Entity  Location 


Entity  Velocity 


Entity  Orientation 


Number  of  Kind  of  Munitions 


br  each  munition 


Muntion  Type 


Number  of  Sensors 


or  each  sensor 


Sensor  ID 


Number  of  Jammers 


or  each  jammer 


Jammer  ID 


Number  of  Tasks 


'or  each  task 


Task  Type 


Entity  ID 


Force  ID 


Entity  Name 


Domain 


Count 


Specific 


Location  X 


Location  Y 


Location  Z 


Velocity  X 


Velocity  Y 


Velocity  Z 


Psi 


Theta 


Phi 


Domain 


Count 


Specific 


Amount 


Integer 


Integer 


Integer  -  enumeration 


Character  Strin 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Float 


Float 


Float 


Float  (meter/sec) 


Float  (meter/sec) 


Float 


Float 


Float 


Integer 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Integer  -  enumeration 


Integer 


Integer 


Character  Strin 


Integer 


Character  Strin 


Integer 


Integer  -  enumeration 


Repeated  as  declared  in  Number  of  Entities 


program  extensibility  by  saving  in  DIS  format,  and  a  new  entity  type  can  be  added  by 
referencing  the  DIS  Enumeration  Document.  The  Entity  Location  Structure  shows  the  initial 
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position  of  the  entity.  For  global  use  of  the  TP,  this  position  must  be  converted  to  a  global 
position.  It  is  also  designed  for  program  extensibility  using  the  coordinates  system  which  DIS 
uses.  The  Entity  Velocity  Structure  indicates  the  initial  speed  of  the  entity  in  meter/sec.  The 
Entity  Orientation  contains  the  entity’s  direction  vector  in  3D  space.  Entity  Velocity  and 
Entity  Orientation  also  use  the  DIS  format.  The  Number  of  Kind  of  Munitions  field  shows 
the  munitions  load  of  the  entity.  For  example,  an  F- 16  can  carry  six  US  Mavericks,  two  US 
Sidewinders,  15  US  Mk82s,  and  2,000  US  M50s.  In  this  case  the  Number  of  Kind  of 
Munitions  field  is  four.  The  Munitions  Type  also  follows  IST94-1.  Some  entities  have 
sensors  and/or  jammers  for  radio  communication.  That  information  is  contained  in  the 
Sensor,  and  Jammer  fields,  respectively.  The  Task  field  indicates  how  many  tasks  the  entity 
will  perform.  There  can  exist  numerous  missions  depending  on  the  specific  characteristics  of 
each  simulation.  I  adopted  the  task  types  which  ModSAF  simulation  currently  uses  for  an 
initial  implementation.  Interested  readers  can  refer  to  Appendix  C  for  more  detail  on  each 
field.  The  Number  of  Entities  in  the  transitional  file  is  given  by  the  ‘Number  of  Entities’ 
entry  declared  on  the  first  line.  In  the  case  where  the  number  of  items  is  initially  unknown, 
memory  requirements  are  minimized  through  dynamic  memory  allocation. 

3.4.5  Translation  Tables 

The  next  several  figures  and  table  represent  the  scenario  file  data  from  each  scenario  source 
and  how  this  data  is  mapped  into  the  TP.  The  left-hand  side  of  the  Table  3.3  shows  the 
number  of  variables  that  are  in  common  area  between  two  scenario  in  each  simulation;  the 
right-hand  side  of  the  table  shows  how  many  variables  are  defined  in  the  TP.  Figure  3.13, 

3. 14,  and  3. 15  depict  the  mapping  of  the  scenario  data  from  ModSAF,  EADSIM,  or 
BATTLESIM,  respectively,  into  the  TP.  These  figures  use  the  same  notation  as  in  [Gard93]. 
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Table  3.3  Percentages  for  Common  Variables  between  Two  Scenario 


Simulation 

to 

Simulation 

Number  of 
Common  Variables 

Number  of 
Common  Variables 
defined  in  TP 

Percentage(%) 

ModSAF  to  EADSIM 

18 

18 

100 

ModSAF  to  BATTLESIM 

21 

21 

100 

EADSIM  to  BATTLESIM 

24 

24 

100 

3.5  Summary 

This  chapter  defines  the  requirements  for  converting  one  scenario  file  to  another.  These 
requirements  can  be  grouped  into  five  main  areas:  first,  defining  a  TP;  second,  loading  a  source 
scenario  of  a  source  simulation;  third,  mapping  the  source  scenario  to  the  TP;  fourth,  remapping 
the  TP  to  a  transitional  target  scenario  prototype,  and  finally,  saving  it  as  a  target  scenario  for  a 
target  simulation.  Specific  implementation  details  of  the  goals  are  discussed  in  the  next  chapter. 
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Figure  3.13  Transitional  Prototype  mapping  for  ModSAF  scenario 
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EADSIM 


Transitional  Prototype 


Figure  3.14  Transitional  Prototype  mapping  for  EADSIM  scenario 


Figure  3.15  Transitional  Prototype  mapping  for  BATTLESIM  scenario 
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IV.  System  Implementation 


4.1  Introduction 

This  chapter  discusses  the  implementation  of  the  Scenario  File  Translator  (SFT)’s  design  defined 
in  Chapter  3.  This  implementation  utilizes  five  subsystems:  a  loading  system,  a  mapping  system, 
a  remapping  system,  a  saving  system,  and  a  user  interface  system.  The  loading  system  reads  a 
source  scenario  and  stores  it  to  a  source  scenario  prototype.  The  mapping  system  transforms  the 
transitional  source  scenario  prototype  to  a  Transitional  Prototype  (TP).  The  remapping  system 
transforms  the  TP  once  more  into  a  transitional  target  scenario  prototype.  The  saving  system 
writes  the  transitional  target  scenario  prototype  as  a  scenario  file  which  can  then  be  run  by  the 
target  simulation.  Finally,  the  user  interface  system  provides  a  Graphics  User  Interface  (GUI)  to 
this  program  easier  to  run.  All  programs  are  written  in  the  C  programming  language  and  were 
tested  on  SGI  and  Sun  Workstations. 

4.2  Loading  a  Scenario  File 

Reading  a  scenario  file  stores  the  scenario  in  computer  memory.  For  this  to  work,  a  data 
structure  which  defines  the  organization  of  the  scenario  is  needed.  This  structure  is  called  the 
transitional  source  scenario  prototype.  Since  the  SFT  operates  three  simulations’  scenario  types, 
this  section  discusses  the  loading  system  for  each  of  the  three  scenarios. 

4.2.1  Loading  a  ModSAF  Scenario  File  There  are  two  ways  to  load  a  ModSAF  scenario  file. 
The  first  way  is  to  use  built-in  libraries  in  the  ModSAF  program  which  do  more  than  simply  read 
the  file  and  the  other  are  to  design  and  develop  a  new  function  to  only  read  the  scenario  file.  Each 
method  has  its  own  advantages  and  disadvantages. 

First,  using  the  ModSAF  built-in  libraries,  we  save  time  since  we  do  not  need  to  design 
and  implement  new  functions;  however,  it  is  necessary  to  include  many  unnecessary  files  even 
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though  a  large  number  of  unused  functions  may  be  contained  in  those  files.  This  results  in 
excessive  compilation  requirements.  This  method  is  inefiScient,  since  the  loading  system  of  the 
SFT  needs  just  one  routine  to  read  a  scenario  file.  Conversely,  designing  and  implementing  a  new 
function  is  attractive,  because  it  simplifies  the  general  organization  of  the  program.  On  the  other 
hand,  this  method  requires  additional  work  for  designing  a  scenario  data  structure  to  implement 
the  loading  system.  Since  program  readability  and  understandability  are  more  important,  I  chose 
to  design  and  implement  a  new  library. 

As  mentioned  in  Section  2. 4. 1.2,  the  structure  of  a  ModSAF  scenario  file  consists  of  two 
parts:  the  Header  part  and  the  Entity  part.  The  Header  part  describes  the  scenario  organization, 
and  the  Entity  part  describes  the  entities  in  the  file.  The  Entity  part  is  also  divided  into  the  File 
Entry  part  and  the  Class  part.  The  File  Entry  part  has  basic  values  for  scenario  class,  and  the 
Class  part  describes  all  about  the  class.  The  most  important  information  in  the  Header  part  is  the 
number  of  entities  in  the  scenario  file.  The  ModSAF  loading  system  reads  classes  individually. 
The  number  of  classes  read  is  given  by  the  number  of  entities.  In  the  File  Entry  part,  the  object 
type  and  the  variant  size  of  the  class  is  also  important.  Moreover,  it  is  necessary  to  combine  the 
classes  with  their  related  entities.  Once  the  scenario  file  has  been  read,  it  is  stored  in  the 
transitional  prototype  data  structure  for  ModSAF  scenarios.  The  minimum  memory  requirement 
to  read  a  ModSAF  scenario  file  with  var5ang  number  of  entities  is  described  in  Table  4.1. 
Examples  shown  are  for  cases  where  each  entity  has  just  one  task. 

4.2.2  Loading  an  EADSIM Scenario  File  Because  EADSIM  scenarios  are  saved  in  a  text 
format,  it  is  relatively  easy  to  understand  their  organization  and  to  develop  an  internal  data 
structure  for  EADSIM  scenario  file  information. 

Two  primary  files  are  needed  to  build  an  EADSIM  scenario:  the  scenario  file  and  the 
laydown  file.  The  laydown  file  stores  all  the  information  about  the  entities  which  compose  a 
scenario,  and  the  scenario  file  describes  initial  setup  conditions  and  references  the  related  laydown 


4-2 


Table  4.1  Required  Memory  Size  for  Loading  a  ModSAF  Scenario  File 


(*  B  :  Bytes) 


Entity 

Header 

Number  of 

Entity 

Part 

Total 

Number 

Part 

Class 

File  Entry  Part 

Class  Part 

(KBytes) 

1 

72  B 

30 

360  B 

3,764  B 

4.1 

100 

72  B 

3,000 

36,000  B 

376,400  B 

405.7 

1,000 

72  B 

30,000 

360,000  B 

3,764,000  B 

4056.7 

10,000 

72  B 

300,000 

3,600,000  B 

37,640,000  B 

40,556.4 

file  names.  Additional  files  are  required  to  organize  a  scenario;  however,  these  two  former  files 
are  more  important  than  the  others. 

To  load  an  EADSIM  scenario,  you  must  know  which  laydown  files  are  connected  to  a 
scenario.  The  laydown  files  are  read  in  order  to  get  the  entity  information  composing  the 
scenario.  Once  this  data  is  stored  in  the  transitional  EADSIM  source  prototype  as  defined  in 
Chapter  3,  then  it  is  possible  to  progress  to  the  next  phase,  the  mapping  phase.  This  stage  is 
discussed  in  the  Section  4.3. 

Loading  an  EADSIM  scenario  is  straightforward;  just  read  the  text  files  into  the 
transitional  EADSIM  source  prototype  data  structure.  In  the  case  of  a  scenario  file,  only  the 
laydovm  file  names  in  this  file  are  important  since  the  remainder  of  its  data  is  only  used  for 
building  the  EADSIM  scenario  itself  However,  the  loading  system  reads  all  the  data  in  an 
EADSIM  scenario  file  for  further  use  since  currently  unused  data  may  be  useful  later. 

In  the  case  of  EADSIM,  the  required  memory  size  of  a  typical  scenario  file  including 
laydown  file  names,  with  one  entity  is  about  8.3  Kbytes.  As  with  ModSAF,  EADSIM  scenario 
file  size  is  dependent  on  the  number  of  entities.  Table  4.2  shows  typical  cases  for  scenarios  with 
varying  number  of  entities. 
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Table  4.2  Required  Memory  Size  for  Loading  an  EADSIM  Scenario  File 
- ^ „ _ (!■■§. . :  .Bytes) 


Entity  Number 

Scenario  File 

Laydown  File 

Total  (KBytes) 

1 

7,509  B 

988  B 

8.3 

100 

7,509  B 

98,000  B 

103.8 

1,000 

7,509  B 

988,000  B 

972.2 

10,000 

7,509  B 

9,880,000  B 

9,655.7 

4.2.3  Loading  a  BATTLESIM Scenario  File  It  is  also  fairly  straightforward  to  load  a 
BATTLESIM  scenario  file,  since  it  is  also  saved  as  a  text  file  like  an  EADSIM  scenario  file.  To 
load  a  BATTLESIM  scenario  file,  the  data  is  extracted  from  each  line  in  the  source  file  into  the 
transitional  BATTLESIM  source  prototype.  When  reading  a  data  line  from  the  source  scenario 
file,  if  the  first  character  of  the  line  is  an  asterisk  defined  by  the  programmer,  it  skips  the  line  and 
reads  the  next  line  automatically  so  that  some  comments  can  be  written  in  the  scenario  file  for 
providing  better  understanding.  Figure  4.1  shows  this  algorithm. 


char  Data_Line[MAX_LINE_LENGTH]; 
while  (!feof(File_Ptr))  /*  read  until  end  of  file  */ 

{ 

/gets  (Data  Line,  MAX JLINE  LENGTH,  File  Ptr); 
switch  (Data  Line [0]) 

{ 


case 

/*  ignore  all  lines  that  starts  with  characters  */ 

case  ‘\n’: 

/*  '\n\  ‘\0  \  or  space  */ 

case  ‘\0’: 

case  ‘ 

break; 

default: 

return  Good  Line; 

/*  Boolean  value  */ 

} 

/*  end  of  switch  */ 

/*  end  of  while  */ 

Figure  4.1  Algorithm  for  Reading  a  BATTLESIM  Scenario  file 
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Assuming  an  entity  has  only  one  route  point,  sensor,  armament,  target,  and  defensive  system  in  a 
BATTLESIM  scenario,  then  276  Bytes  are  needed  for  a  scenario  with  one  entity.  Table  4.3 
describes  these  memory  requirements  for  similar  scenarios  with  different  numbers  of  entities.. 


Table  4.3  Required  Memory  Size  for  Loading  a  BATTLESIM  Scenario  File 


Entity  Number 

Header  Part 

Entity  Part 

Total  (KBytes) 

1 

144  B 

132  B 

0.27 

100 

144  B 

13,200  B 

13.0 

1,000 

144  B 

132,000  B 

129.1 

10,000 

144  B 

1,320,000  B 

1,289.2 

4.2.4  Loading  a  Transitional  File  As  will  be  seen  in  Section  4.5.4,  a  Transitional  File  is  also 
saved  in  text  format  so  it  can  be  easily  verified  when  viewing  the  components  in  it.  A 
Transitional  File  is  read  and  loaded  into  the  Transitional  Prototype  data  structure  using  the  same 
algorithm  for  loading  a  BATTLESIM  scenario  file. 

The  required  memory  size  for  each  entity  in  the  TP  depends  on  the  entity’s  number  of 
tasks.  If  an  entity  has  an  ‘Assault’  task  (the  largest  task  with  respect  to  memory  requirements), 
the  entity  needs  271  Bytes.  This  is  shown  in  Table  4.4  with  other  examples. 


Table  4.4  Required  Memory  Size  for  Loading  Transitional  File 
...  ,  .  .  ,  , - . - r  B  :  Bytes) 


Entity  Number 

Without  Task 

Task 

Total  (KBytes) 

1 

218B 

53  B 

0.26 

100 

21,800  B 

5,300  B 

26.4 

1,000 

218,000  B 

53,000  B 

264.6 

10,000 

2,180,000  B 

530,000  B 

2,646.4 
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4.3  Mapping  a  Scenario  Prototype  to  a  Transitional  Prototype 

Mapping  to  a  Transitional  Prototype  (TP)  is  necessary  to  convert  a  source  scenario  to  a  target 
scenario.  The  more  source  types  we  map  to  the  TP,  the  more  data  we  remap  to  target  scenario 
prototype  and  the  more  we  increase  the  conversion  percentage.  This  results  in  a  more  well- 
translated  target  scenario.  Because  the  SFT  uses  scenarios  from  three  simulations,  six  mapping 
routines  are  needed.  This  is  because  each  simulation  needs  two  mapping  routines:  one  to  the  TP 
from  the  transitional  source  scenario  prototype,  and  another  from  the  transitional  target  scenario 
prototype  to  the  TP.  This  section  discusses  mapping  a  transitional  source  scenario  prototype  to 
the  TP.  Section  4.4  discusses  remapping  the  TP  to  a  transitional  target  scenario  prototype. 

4.3.1  Mapping  a  ModSAF  Prototype  to  a  Transitional  Prototype  A  ModSAF  scenario  file  is 
stored  internally  as  a  transitional  ModSAF  prototype  as  defined  in  Section  3.  Mapping  from  this 
structure  to  the  TP  is  done  by  traversing  the  stored  structure.  Ten  of  the  21  ModSAF  classes  are 
essential  for  mapping  to  the  TP.  They  are  the  Overlay  Class,  the  Point  Class,  the  Line  Class,  the 
Sector  Class,  the  Unit  Class,  the  Task  Class,  the  Task  State  Class,  the  Task  Frame  Class,  the 
Task  Authorization  Class,  and  the  Minefield  Class.  Among  them,  four  classes  are  more  useful 
for  mapping  to  the  TP  (see  Figure  3.13).  To  begin,  it  is  necessary  to  determine  how  many  entities 
there  are  in  a  scenario  file.  The  number  of  the  entities  is  same  as  the  Unit  Class  number  in  the 
ModSAF  scenario  file.  If  the  number  of  the  entities  in  a  scenario  file  is  50,  then  the  Unit  Class 
number  is  also  50.  Thus,  if  Unit  Class  number  is  determined  while  traversing  the  transitional 
ModSAF  prototype,  the  number  of  the  entities  in  the  TP  is  found  easily.  Since  the  Unit  Class  has 
direct  information  of  Entity  ID,  Force  ID,  and  Entity  Name  in  the  TP,  every  time  a  Unit  Class  is 
detected  they  are  mapped  to  the  TP  using  these  items.  The  TP  Entity  Type  is  stored  in  the  DIS 
format  which  has  Domain,  Country,  Category,  SubCategory,  and  Specific  values.  The  variable 
objectT5^e  in  a  Unit  Class  is  related  to  the  DIS  format  by  a  ModSAF  function  which  converts 
this  variable  to  the  DIS  format. 


4-6 


Since  ModSAF  entity  location  uses  the  topocentric  coordinate  system  in  which  the  origin 
of  the  coordinates  is  given  point,  we  cannot  directly  use  these  coordinates  within  the  TP.  It  is 
necessary  to  match  this  location  to  the  DIS  geocentric  coordinates.  The  origin  of  the  geocentric 
coordinate  system  in  DIS  is  the  centroid  of  the  earth  as  shown  at  Figure  4.2  [IST94].  ModSAF 
also  provides  a  function  to  support  this  conversion. 


Figure  4.2  Geocentric  Cartesian  Coordinates  in  DIS 


Since  ModSAF  must  map  Entity  Velocity  and  Entity  Orientation  to  DIS  formats  when  it 
sends  DIS  PDUs,  we  can  also  use  functions  to  build  the  TP.  The  kind  of  munitions  in  an  entity  is 
known  from  a  ‘munition’  variable  in  a  Unit  Class  of  ModSAF  scenario  file.  Another  ModSAF 
function  converts  this  object  type  to  a  DIS  format  is  also  used  here.  The  amount  of  munition  that 
the  entity  has  is  also  stored  in  the  ‘munition’  variable  in  a  Unit  Class.  The  Task  Type  in  the  TP 
can  be  determined  after  integrating  several  classes  in  the  ModSAF  scenario  file.  Some  classes 
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which  help  to  determine  the  TP  Task  Type  are  the  Task  Class,  the  Task  State  Class,  the  Task 
Frame  Class,  and  the  Task  Authorization  Class.  ModSAF  2.1  defines  33  tasks,  and  the  SFT 
accommodates  all  of  them  to  provide  a  complete  task  mapping.  Appendix  B  shows  the  task  types 
defined  within  the  TP. 

4.3.2  Mapping  an  EADSIM  Prototype  to  a  Transitional  Prototype  Of  the  two  data  structures 
in  the  EADSIM  prototype,  i.e.,  one  for  the  scenario  file  and  the  other  for  a  laydown  file,  only  the 
data  structure  corresponding  to  the  laydown  file  can  be  directly  mapped  into  the  TP  since  the  data 
in  the  scenario  file  is  EADSIM  specific  except  for  the  laydown  file  names.  Specifically,  five  data 
items  from  the  laydown  data  structure  cover  almost  every  part  of  the  TP.  The  Entity  ID  and  the 
Entity  Task  in  the  TP  Entity  Header  are  not  known  directly  from  the  laydown  file,  so  the  most 
widely  used  default  values  are  put  into  them.  The  Entity  ID  is  produced  sequentially  whenever  an 
Entity  is  detected,  and  when  the  entity  is  an  aircraft  the  Entity  Task  is  either  ‘Assault  Ground 
Target’  or  ‘CAS  Mission’  since  it  is  required  to  attack  all  enemy  forces  on  its  path  (See  Figure 
3.14). 

We  determine  the  Force  ID  in  the  Entity  Header  part,  whether  it  is  friendly  or  an  enemy 
force,  after  checking  the  System  ID  in  an  EADSIM  scenario  file.  The  TP  Entity  Name  is  known 
when  referring  to  the  EADSIM  Military  ID.  The  TP  Entity  Type  is  saved  as  an  enumeration  type 
in  DIS  format  using  the  EADSIM  System  ID.  Although,  there  is  no  item  in  the  EADSIM 
prototype  which  indicates  an  entity’s  initial  location,  the  starting  location  can  be  determined  as 
the  first  point  in  the  path  the  entity  passes  through.  This  point  must  also  be  changed  to  a  DIS 
geocentric  coordinate  system  value. 

We  derive  the  TP  Entity  Orientation  by  computing  the  difference  between  the  first  and  the 
second  entity  positions  in  its  path.  This  difference  is  converted  to  the  DIS  format,  and  stored  to 
the  Entity  Orientation  in  the  TP .  An  entity’s  munition  load  is  determined  by  referencing  another 
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file  in  EADSIM  using  the  System  ID  of  the  entity.  This  data  must  be  converted  into  the  DIS 
format.  The  Sensor  Name  and  the  Jammer  Name  are  determined  from  the  platform  of  the  entity 
directly. 

4.3.3  BATTLESIM Prototype  to  Transitional  Prototype  The  BATTLESIM  prototype  consists 
of  the  Header  part  and  the  Entity  part  as  described  at  Section  2A.3.2.  The  items  in  the  Header 
part  to  match  to  the  TP  include  the  icon  definition  records  as  well  as  the  minimiitn  and  maximum 
coordinates  of  a  terrain  database.  Minimum/maximum  coordinates  are  needed  when  converting 
the  entity  position  to  geocentric  coordinate  system  in  DIS,  and  Icon  Definition  Records  are  for  the 
type  of  the  entity.  The  datum  that  is  not  mapped  directly  to  the  TP  from  a  BATTLESIM 
prototype  is  the  Task  Type.  We  use  the  most  widely  accepted  default  values  here.  In  case  of  an 
aircraft,  we  set  the  Task  Type  to  either  ‘Assault  Ground  Target’  or  ‘CAS  Mission.’  The  task 
‘Assault’  or  ‘Move  Task’  is  used  for  a  ground  entity. 

We  derive  the  TP  Entity  ID  from  the  BATTLESIM  object  ID.  Icon  Name  determines  the 
Force  ID,  Entity  Name,  and  Entity  Type  of  the  TP.  Entity  with  US  icon  name  is  recognized  as 
friendly;  Soviet  icon  name  characterizes  entity  as  an  enemy.  Otherwise,  the  entity  is  regarded  as 
‘others.’  The  TP  Entity  Type  is  also  determined  by  the  icon  name  and  translated  into  the  DIS 
format.  Table  4.5  gives  some  examples  for  mapping  the  BATTLESIM  icon  name  to  a  DIS  Entity 
name. 


Table  4.5  Icon  Name  in  BATTLESIM  vs.  Entity  Name  in  DIS 


Icon  Name  in  BATTLESIM 

Entity  Name  in  DIS 

fl8 

FA18 

mig 

USSR  Mig21 

missile 

US  CG41 

tank 

US  MlAI 

truck 

US  M35A2 
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The  TP  Entity  Location  is  calculated  using  the  coordinates  of  the  entity  and  the 
minimum/maximum  coordinates  of  the  terrain  file  in  the  BATTLES IM  scenario  file.  The  TP 
Entity  Velocity  and  the  TP  Entity  Orientation  are  described  in  the  BATTLESIM  scenario  file; 
however  they  must  be  converted  into  the  DIS  format.  The  munition  type  of  an  Entity  is  related  to 
the  BATTLESIM  armament  type;  however,  it  cannot  be  used  directly  in  the  TP,  but  is  converted 
to  DIS  format.  The  entity’s  Sensor  ID  and  the  Jammer  ID  are  related  to  the  Sensor  Name  and 
Defensive  system  in  BATTLESIM. 

4.4  Remapping  a  Transitional  Prototype  to  a  Transitional  Target  Scenario  Prototype 
In  the  process  of  converting  a  TP  to  a  target  scenario  prototype,  some  items  which  are  not 
represented  by  the  target  scenario  are  lost.  In  addition,  it  is  also  often  necessary  to  generate 
unspecified  parameters  as  default  values  in  a  target  scenario  prototype. 

4.4. 1  Transitional  Prototype  to  ModSAF  Scenario  Prototype  To  make  a  file  which  ModSAF 
can  read  after  remapping  from  a  TP,  it  could  be  accomplished  by  a  function  fitting  the  data 
structure  of  ModSAF  scenario  file.  I  think  the  best  approach  to  create  the  ModSAF  target  file  is 
to  use  a  routine  which  ModSAF  provides.  It  is  necessary  to  map  into  a  Persistent  Object  (PO) 
database  for  saving  as  a  scenario  of  ModSAF.  Since  much  information  about  Semi-Autonomous 
Forces  (SAF)  behavior  cannot  be  shared  via  the  DIS  protocol,  the  PO  protocol  was  created  to 
provide  a  more  flexible  and  scaleable  interface  between  the  components  of  the  SAF  system.  The 
PO  protocol  enables  the  sharing  of  behavioral  states,  command  and  control  information,  and 
system  administration.  ModSAF  software  modules  have  unlimited  access  to  all  the  information 
being  broadcast  via  this  protocol,  provided  they  are  running  on  the  same  PO  ‘database  ID.’  The 
database  ID  is  an  identifier  in  the  PO  PDU  Header  that  identifies  with  which  repository  of 
persistent  objects  or  ‘database’  the  application  interacts. 
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ModSAF  program  provides  a  function  ‘po  create  objectO’  which  creates  an  entity  in  the 
PO  database.  We  use  the  function  to  build  of  each  ModSAF  class.  Ten  of  21  (see  section  4.3.1) 
ModSAF  classes  are  involved  when  remapping  to  a  ModSAF  scenario  file.  Among  these,  the 
Unit  Class  has  the  most  important  role.  This  class  stores  the  general  data  of  an  entity.  The 
matching  items  from  the  TP  are  ‘overlaylD,'  ‘forcelD,'  ‘objectType,'  ‘marking,'  ‘location,' 
‘direction,'  ‘speed,'  and  ‘munition’  of  the  Unit  Class  (see  Figure  4.3).  The  ModSAF  overlaylD  is 
mapped  from  the  TP  Entity  ID,  and  the  ModSAF  objectType  is  converted  from  the  data  that  is 
saved  in  DIS  format  to  an  integer  type  variable  through  a  ModSAF  utility  function. 

The  marking  in  the  Unit  Class  is  copied  from  the  TP  entity  name.  Getting  the  ModSAF 
location  value  requires  a  routine  to  convert  the  DIS  format  data  in  the  TP  into  ModSAF  terrain 
database.  Direction,  speed,  and  munition  in  the  Unit  Class  are  passed  in  the  same  way  as 
ModSAF  location  data.  Translating  the  TP  task  into  each  ModSAF  Task  class  is  required  to  map 
related  data  using  the  TP  Task  Type  module.  After  accomplishing  this,  we  build  the 
PO_database. 

4.4.2  Transitional  Prototype  to  EADSIM  Scenario  Prototype  In  section  2  4.2.2,  we  mentioned 
that  EADSIM  uses  two  files  to  build  a  scenario.  Here  we  describe  the  process  of  mapping  from 
each  TP  entity  to  the  EADSIM  scenario  prototype.  The  laydown  file  name  is  contained  in  the 
scenario  data  structure.  This  file  contains  the  platform  data  of  each  EADSIM  entity. 

The  EADSIM  program  allows  several  laydown  files  in  a  single  scenario;  however,  the 
SFT  uses  only  one  laydown  file  to  save  all  entities  in  the  TP.  Since  this  file  has  all  the 
information  of  a  scenario,  we  only  need  to  open  this  one  file  when  we  want  to  see  what  entities  are 
in  the  scenario.  The  EADSIM  Military  ID  of  an  entity  is  same  as  the  TP  Entity  Name.  The 
EADSIM  System  ID  can  be  obtained  using  the  TP  Entity  Type.  The  Sensor  Name  and  the 
Jammer  Name  in  the  EADSIM  prototype  are  also  derived  from  the  TP.  The  TP  did  not  provide 
EADSIM  Way  Point  directly;  however,  we  can  derive  the  data  from  the  TP  task  type.  If  an  entity 
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has  a  task,  a  route  which  the  entity  should  follow  is  stored  in  the  TP.  The  Way  Point  can  be  built 
using  these  route  data. 

4. 4. 3  Transitional  Prototype  to  BA  TTLESIM  Scenario  Prototype  A  BATTLESIM  scenario 
prototype  contains  a  Header  Part  and  an  Entity  Part.  The  data  needed  to  map  to  the  Header  Part 
is  the  Icon  Definition  part.  For  determining  these  icon  definition  records,  it  is  necessary  to 
describe  the  Header  Part  after  extracting  the  kinds  of  entities  which  are  stored  in  Entity  Part.  The 
BATTLESIM  entity  object  type  determines  the  icon  number  which  matches  with  the  TP  Entity 
Type.  The  TP  Entity  ID  determines  the  BATTLESIM  object  ID.  The  BATTLESIM  coordinates 
are  found  using  both  the  TP  location  and  minimum/maximum  coordinates  as  described  in  the 
Header  Part. 

The  BATTLESIM  Velocity  and  Orientation  are  derived  from  the  TP  velocity  and  the 
orientation.  The  sensor  name  and  the  defensive  system  are  recognized  by  the  Sensor  ID  and  the 
Jammer  ID,  respectively.  Finally,  the  armament  of  an  entity  can  be  derived  from  the  TP’s 
munition  type. 

The  next  three  figures  represent  the  transitional  prototype  how  its  data  is  mapped  into 
each  target  scenario  prototype.  The  size  of  each  box  is  not  intended  to  represent  the  actual  file 
size. 
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Figure  4.3  Remapping  to  a  Transitional  ModSAF  Prototype 
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Figure  4.4  Remapping  to  a  Transitional  EADSIM  Prototype 


Figure  4.5  Remapping  to  a  Transitional  BATTLESIM  Prototype 
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4.5  Saving  a  Transitional  Prototype  as  a  Target  Scenario 

The  last  phase  of  translating  a  source  scenario  to  a  target  scenario  is  to  write  the  remapped  target 
prototype  as  a  target  scenario  that  a  target  simulation  can  read. 

4.5.1  Saving  as  a  ModSAF  Scenario  Since  a  PO_database  is  created  in  the  process  of 
mapping  into  the  transitional  ModSAF  prototype,  the  task  of  saving  the  PO_database  into  an 
actual  file  is  very  simple.  We  use  a  function  provided  by  the  ModSAF  program.  When  using  the 
function,  all  the  data  in  PO_database  are  stored  into  a  user  defined  file  name. 

4.5.2  Saving  as  an  EADSIM  Scenario  The  first  thing  to  do  is  to  save  a  scenario  file  which  ah 
EADSIM  can  read  fi-om  transitional  EADSIM  prototype.  At  this  time,  there  is  nothing  to  get 
from  the  transitional  EADSIM  prototype.  Only  the  laydown  file  name  is  designated  by  user  input 
and  all  information  of  a  scenario  is  stored  here.  Several  different  file  paths  are  stored  in  the 
EADSIM  scenario  file,  and  the  directory  path  that  is  running  the  EADSIM  is  also  needed. 

Because  typing  in  the  directory  path  whenever  the  Scenario  File  Translator  is  running  is 
inefficient,  we  store  the  EADSIM  running  directory  path  in  a  files.  This  makes  the  SFT  run  more 
efficiently.  The  laydown  file  that  stores  the  information  of  an  entity  is  written  to  a  text  file  fitting 
the  transitional  EADSIM  prototype.  The  transitional  EADSIM  Laydown  prototype  can  be  saved 
in  a  straightforward  manner  since  it  is  designed  the  same  as  the  data  structure  of  the  laydown  file. 

4.5.3  Saving  as  a  BATTLESIM Scenario  To  save  a  transitional  BATTLESIM  prototype  data 
structure,  we  simply  write  the  items  in  the  structure  to  disk  sequentially.  Because  there  is  no  way 
to  determine  the  terrain  filename  or  the  data  about  BATTLESIM  section,  thus,  the  user  must 
provide  the  values  when  the  file  is  saved. 

4.5.4  Saving  as  a  Transitional  File  Sometimes  it  is  necessary  to  save  the  Transitional 
Prototype  itself  for  further  uses  after  mapping  the  source  scenario  to  the  TP.  This  is  also 
efficient  when  testing  a  scenario  in  several  other  simulations  since  the  SFT  just  needs  to  read  a 
source  scenario  one  time.  Once  the  SFT  reads  a  source  scenario  converts  it,  and  saves  it  as  a  TP, 
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there  is  no  need  to  re-read  and  remap  the  scenario  for  testing  with  other  simulations.  Just  reading 
the  Transitional  File  is  enough  to  convert  the  source  scenario  to  a  target  scenario.  Saving  as  a 
Transitional  File  means  to  write  the  items  that  have  been  mapped  to  the  TP  in  the  format  of 
Transitional  Prototype.  The  SFT  saves  the  TP  to  a  text  format.  The  user  can  easily  understand 
the  data  since  the  SFT  also  writes  some  comments  in  the  file. 

4.6  User  Interface 

This  section  presents  the  result  of  the  SFT  user  interface.  The  SFT  provides  two  interfaces;  GUI 
and  Command  Line  Interface  (CLI).  Basically  the  CLI  is  provided  to  every  machine  even  in  the 
places  where  the  GUI  is  also  available. 

4. 6. 1  Graphics  User  Interface  (GUI)  Figure  4.6  is  a  picture  of  the  SFT  main  window.  The 
row  of  menus  at  the  top  of  the  window  (New,  Run,  Quit,  and  Help)  allows  immediate  access  to 
several  functions.  A  selection  of  the  ‘New’  button  initializes  the  SFT.  The  ‘Run’  button  causes 
the  SFT  to  translate  a  source  scenario  to  a  user-defined  target  scenario  according  to  the  current 
settings.  If  a  necessary  value  is  omitted,  the  SFT  displays  an  error  message.  The  ‘Quit’  button 
terminates  the  program,  and  the  ‘Help’  button  displays  program-specific  information  to  the  user. 

The  rest  of  the  main  window  is  called  a  scenario  selection  area.  It  is  divided  into  two 
areas:  the  source  scenario  area  and  the  target  scenario  area.  Both  sides  have  same  purpose, 
namely,  to  select  a  scenario  type  and  a  scenario  file  name. 
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Figure  4.6  The  Main  Window  of  the  SFT 
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The  scenario  selection  area  allows  the  user  to  choose  the  source/target  simulation.  The  user  can 
type  a  directory  path  and  a  file  name  in  the  ‘FileName’  display  area  or  can  use  Tile  Browse’ 
button  to  search  the  directory  structure  for  a  file  name.  Error  messages,  warning  messages,  or 
processing  messages  are  displayed  in  one  of  several  different  types  of  windows. 

4,6.2  Command  Line  Interface  A  command  line  interface  is  also  supported  by  the  SFT  for 
when  the  Motif  library  is  not  available.  To  use  this  interface,  the  user  types  the  kind  of  a 
source/target  simulation  and  the  name  of  a  source/target  scenario  file.  The  SFT  then  builds  the 
target  scenario  file  which  the  user  defined.  This  interface  has  a  validating  function  so  it  filters 
errant  inputs.  Appendix  C  shows  the  usage  of  SFT  Command  Line  Interface. 

4.7  Summary 

This  chapter  described  how  the  Scenario  File  Translator  system  is  implemented.  The  SFT 
has  five  subsystems:  the  loading  system,  the  mapping  system,  the  remapping  system,  the  saving 
system,  and  the  user  interface  system.  Actual  data  structures  and  methods  for  implementing  the 
program  followed  the  design  specification.  The  next  chapter  presents  the  results  of  this  system 
and  offers  suggestions  for  future  work. 
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F.  Results 


5.1  Introduction 

This  chapter  discusses  the  approach  taken  to  ensure  that  the  system,  as  implemented,  fulfills 
the  original  requirements.  Several  cases  are  tested  and  the  results  are  illustrated  using  a 
series  of  pictures  taken  within  the  SFT.  This  chapter  also  describes  my  observations  of  the 
test  results. 

5.2  The  Scenario  File  Translator  Test  Cases 

There  are  nine  different  test  cases  represented  in  the  SFT.  They  are  referred  to  as  Test  1 
through  Test  9.  Each  test  case  represents  a  different  t3^e  of  conversion.  This  section  shows 
what  a  source  scenario  looks  like  in  a  source  simulation  and  not  its  translated  scenario  as 
represented  in  the  target  simulation. 

5.2. 1  Test  1 :  ModSAF  to  EADSIM  Figure  5.1  is  a  picture  of  a  ModSAF  simulation 
produced  by  ModSAF  itself  It  has  18  entities,  and  each  entity  has  a  different  task.  This 
scenario  is  used  for  Test  1,  Test  2,  and  Test  3.  Figure  5.2  shows  the  ModSAF  scenario  after 
EADSIM  scenario  and  executed  by  EADSIM.  It  also  has  18  entities  which  is  the  same  as  the 
number  of  entities  in  the  ModSAF.  Additionally,  every  entity  location  is  the  same  as  the  one 
in  the  ModSAF,  and  every  task  for  the  ModSAF  entities  is  also  properly  converted  to  the 
EADSIM  scenario. 

5.2.2  Test  2  :  ModSAF  to  BATTLESIM  Since  the  ModSAF  scenario  is  already  converted 
to  the  Translated  File  in  the  Test  1,  there  is  no  need  to  read  the  ModSAF  scenario  again. 

After  converting  the  Transitional  File  to  the  BATTLESIM  format,  it  also  has  18  entities. 
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Once  again,  everything  in  the  ModSAF  scenario  was  properly  translated  to  the  BATTLESIM 
scenario. 

5.2.3  Test  3  :  ModSAF  to  ModSAF  It  is  interesting  to  “convert”  the  ModSAF  scenario  to  a 
ModSAF  scenario  after  mapping  it  to  the  Transitional  File,  since  the  comparison  between  two 
scenarios  demonstrates  the  fidelity  of  the  conversion,  showing  clearly  what  is  and  is  not 
mapped.  Figure  5.3  shows  a  translated  scenario  from  a  ModSAF  source  scenario  to  a 
ModSAF  target  scenario.  Notice,  there  are  no  changes  between  Figure  5.1  and  Figure  5.3. 

The  basic  elements  of  the  scenario  are  well  translated  with  lost  data  during  the  mapping 
process  restored  by  proper  default  values. 

5.2.4  Test  4  :  EADSIM  to  ModSAF  Figure  5.4  is  a  snapshot  of  an  EADSIM  scenario.  It 
has  10  entities,  and  each  entity  has  a  different  flight  path  and  mission.  This  particular 
EADSIM  scenario  is  used  for  Test  4,  Test  5,  and  Test  6.  Figure  5.5  is  a  picture  of  a 
ModSAF  simulation  executing  a  converted  scenario  from  the  EADSIM  by  the  SFT.  Some 
entities  which  are  not  represented  in  ModSAF  (such  as  an  EADSIM  ‘Air  Base’)  are  translated 
into  the  ‘unknown’  entity. 

5.2. 5  Test  5  :  EADSIM  to  BATTLESIM  The  number  of  entities  in  the  BATTLESIM  is 
the  same  as  the  number  of  entities  in  the  EADSIM  even  after  converting  the  scenario.  Each 
BATTLESIM  entity  has  the  same  route  with  an  EADSIM  entity  route  to  perform  the  mission 
in  the  EADSIM  source  scenario. 
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5.2.6  Test  6  :  EADSIM to  EADSIM  I  also  tested  converting  an  EADSIM  scenario  to  an 
EADSIM  scenario  through  the  Transitional  File.  Figure  5.6  shows  the  playback  of  the  target 
scenario  after  its  conversion  by  the  SFT.  There  are  no  changes  between  Figure  5.4  and 
Figure  5.6  similar  to  that  of  Test  3,  ModSAF  to  ModSAF.  The  result  scenario  file  has  just 
one  laydown  file.  It  successfully  combined  several  laydown  files  into  one  laydown  file. 

5.2. 7  Test  7 :  BATTLESIM to  ModSAF  Figure  5.7  depicts  ModSAF  scenario  as  it 
executes  the  scenario  after  being  converted  from  BATTLESIM  by  the  SFT.  BATTLESIM 
source  scenario  has  9  entities,  and  each  entity  has  a  different  path.  ModSAF  shows  each 
entity  has  its  origin  path  and  proper  mission  fitting  the  ModSAF  task. 

5.2.8  Test  8  :  BATTLESIM  to  EADSIM  Figure  5.8  shows  a  snapshot  of  a  simulation  run 
by  EADSIM.  There  is  the  same  number  of  entities  in  the  BATTLESIM,  and  every  entity 
location  in  the  BATTLESIM  is  well  translated  into  an  EADSIM  location.  The  entity  path  in 
BATTLESIM  is  also  transferred  into  EADSIM,  so  every  entity  which  has  a  path  goes  through 
with  the  translated  path. 

5.2.9  Test  9  :  BATTLESIM  to  BATTLESIM  I  compared  file  format  and  file  size  after 
translating  the  original  BATTLESIM  scenario  to  the  translated  BATTLESIM  scenario. 
Actually  there  are  no  differences  between  them.  So,  translating  BATTLESIM  scenario  into 
another  scenario  has  successfully  worked. 
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5.4  Observation 


We  tested  each  possible  case  with  our  three  simulations.  The  tests  are  demanding,  because  in 
each  case  the  source  scenario  I  produced  most  of  its  special  purpose  features.  Thus,  I  could 
also  test  the  interoperability  between  heterogeneous  simulations. 

According  to  these  tests,  we  can  make  the  following  observations: 

•  Every  entity  type  in  a  source  scenario  was  completely  translated  into  a  target  scenario. 

•  Every  location  in  a  source  scenario  is  converted  as  the  same  position  in  a  target  scenario. 

•  The  task  definition  in  the  TP  covered  every  scenario’s  task  type. 

•  The  choice  to  use  the  DIS  format  data  for  Transitional  Prototype  (TP)  such  as  entity  type, 
entity  location,  entity  velocity,  entity  orientation  and  entity  munition  type  was  a  good 
decision. 

•  It  was  shown  that  using  the  intermediate  format  to  correct  a  source  scenario  to  a  target 
scenario  is  a  better  method  than  a  direct  mapping.  Assume  there  are  currently  N 
simulations.  In  case  of  a  direct  mapping  method,  N*(N-1)  =N^  -  N  routines  are  needed; 
however,  only  2*N  routines  are  needed  with  using  an  intermediate  format. 

Based  on  these  observations,  the  general  objectives  which  are  defined  in  Chapter  Three  are 
accomplished. 

5.5  Summary 

This  chapter  discussed  the  top-level  of  the  SET  organization,  and  the  test  results.  It  also 
provided  the  observation  of  these  test  cases  for  converting  a  scenario  to  a  target  scenario. 

The  next  chapter  formulates  some  conclusions  and  provides  some  recommendations  for  future 
work. 
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Figure  5.1  A  Source  Scenario  ofModSAF 
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Figure  5.3  A  Converted  ModSAF  Scenario  from  ModSAF 


Figure  5.4  A  Source  Scenario  of  EADSIM 
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Figure  5.5  A  Converted  ModSAF  Scenario  from  EADSIM 


Figure  5.6  A  Converted  EADSIM  Scenario  from  EADSIM 
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Figures.?  A  Converted  ModSAF  Scenario  from  BATTLESIM 


Figure  5.8  A  Converted  EADSIM  Scenario  from  BATTLESIM 
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VI.  Thesis  Summary 


6.1  Introduction 

The  effectiveness  of  computer  simulation  in  the  military  is  especially  apparent,  since  real 
combat  conditions  are  often  costly  to  create  for  testing  some  scenarios.  There  now  exists  a 
variety  of  scenario  generation  and  analysis  products  which  have  differing  purposes  and 
functions.  Due  to  the  particular  purpose  of  each  simulation,  we  cannot  use  one  scenario  of  a 
simulation  directly  with  another  simulation  without  a  translator  since  there  is  no  standard 
scenario  format.  Interoperability  between  simulations  is  becoming  more  important  in  large 
scale  simulation  and  distributed  exercises.  Translating  scenarios  to  support  interoperability  is 
a  useful  process.  I  chose  to  remap  to  a  target  simulation  after  mapping  into  an  intermediate 
prototype.  This  is  more  efficient  because  it  is  not  dependent  on  the  number  of  existing 
simulations.  I  proposed  the  transitional  prototype  as  an  intermediate  format,  and  also 
developed  the  software  tool  (Scenario  File  Translator)  that  aids  in  the  translation  of  scenario 
file  formats  with  this  transitional  prototype  so  that  scenarios  developed  by  different 
simulations  can  be  run  by  each  other.  After  some  test  cases  with  the  SFT,  this  scenario 
translating  work  has  been  achieved. 

6.2  Recommendations  for  Future  Work 

There  are  several  approaches  for  follow-on  work  in  the  SFT.  One  of  the  biggest  areas  of 
concern  in  the  system  is  how  the  definition  of  the  Transitional  Prototype  (TP)  can  be  made 
more  general.  The  prototype  that  covers  all  of  the  information  of  all  simulation  is  the  ideal 
format  for  this  work.  Table  6.1  is  a  snapshot  of  the  work  proposed  in  this  chapter.  Each  of 
the  primary  system  components  -  transitional  prototype,  DIS  PDU,  compatibility,  and 
machine  independence  -  is  a  candidate  for  future  work. 
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6.2.1  Transitional  Prototype  As  mentioned  in  Section  3.4.3,  a  set  of  information  which 
covers  all  data  for  all  simulations  is  the  ideal  format  for  the  TP.  However,  this  is  not 
practical,  and  therefore  we  might  focus  on  improving  the  data  structures  and  the  data  formats 
in  the  TP  as  the  best  way  to  cover  every  simulations’  scenario.  As  the  TP  data  structure  is 
generalized  it  will  provide  program  for  greater  reusability  and  extensibility.  A  more  detailed 
definition  of  the  task  type  allows  the  target  scenario  to  inherit  the  special  purpose  of  a  source 
scenario.  We  can  also  enhance  the  mapping  process  for  more  accurate  translation.  Since  the 
more  we  map  to  the  TP  the  more  we  extend  the  common  area  between  simulations,  even  a 
small  piece  of  data  is  important.  Since  the  most  widely-used  default  values  are  used  when 
there  is  no  represented  data  to  a  target  scenario  for  mapping,  finding  a  correct  value  for  those 
data  is  another  important  process  to  increase  the  conversion  percentage  between  two 
simulations. 

6.2.2  DIS PDU  Since  most  distributed  simulations  support  DIS,  grabbing  the  PDU  from 
the  network  and  building  a  state  of  the  battlefield  provides  another  advantage.  Even  if  the 
mapping  procedure  of  a  simulation  is  not  built,  we  can  extract  the  current  state  of  a  scenario 
and  can  save  it  as  the  Transitional  File  which  can  be  used  by  another  simulation.  The  best 
PDU  to  determine  the  current  state  of  a  scenario  is  the  ‘Entity  State  PDU’  (see  Table  2.1). 
The  PDU  has  information  of  each  entity  such  as  entity  type,  velocity,  and  location.  Using  the 
PDU  we  can  rebuild  a  scenario  which  contains  all  the  simulations  on  the  network.  Of  course, 
we  can  select  some  specific  PDUs  by  ‘Exercise  ID’  in  PDU  Header.  However,  since  DIS 
PDUs  send  current  events  over  the  network,  it  is  not  possible  to  determine  the  task  of  an 


6-2 


Table  6. 1  Proposed  Future  Work 


Functional  Area 

Proposed  Work 

Transitional  Prototype 

Improving  data  structure  and  data  format 

Extend  the  type  of  task 

Enhance  accuracy  of  mapping  process 

Correct  inserting  for  default  values 

DIS  PDU 

Develop  DIS  “Entity  State  PDU”  snapshot  function 

Select  specific  PDU  with  Exercise  ID  in  PDU  Header 

Changing  TP  to  DIS  PDU 

Send  converted  DIS  PDU  from  TP  via  network 

Receive  other  DIS  PDUs  relating  the  TP 

Machine  Independence 

Provide  ‘Makefile’  to  compile  on  any  machine 

Analyze  the  computer  system  to  allocate  optimized  memorv'  size 

Enhance  stability  and  extensibility 

Compatibility 

Accommodate  other  prototype 

Transfigure  to  other  format 

Accompany  with  DIS  PDU 

entity  as  described  in  Section  3. 2. 1.1.  As  DIS  PDU  is  more  well  developed  we  can  alleviate 
this  problem.  Conversely,  we  can  build  a  procedure  which  changes  a  TP  to  PDUs  because  the 
TP  already  uses  the  DIS  format.  That  is  another  benefit  since  we  can  send  the  TP  via  the 
network  through  the  DIS  PDU,  providing  for  program  extensibility. 

6.2.3  Machine  Independence  It  is  desirable  for  the  SFT  to  run  on  any  machine  to  support 
many  currently-existing  simulations.  Of  course,  there  is  a  way  to  translate  a  scenario  on  one 
type  of  machine  to  a  target  scenario  on  another  type  of  machine.  When  the  scenarios  are 
transferred  to  the  machine  which  has  the  SFT,  a  target  scenario  can  be  made  and  can  be  sent 
to  the  machine  which  uses  the  target  scenario.  However,  it  depends  on  the  network  state.  For 
more  stable  support,  it  is  necessary  to  compile  on  any  machine.  The  flexible  and 
comprehensive  ‘Makefile’  supports  this. 
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6.2.4  Compatibility  I  chose  DIS  format  to  save  some  scenario  data  such  as  entity  type, 
entity  location,  and  munition  type.  If  a  more  well-defined  format  to  send  a  current  state  of  a 
scenario  is  developed,  or  if  there  is  another  format  to  describe  data  of  scenarios,  compatibility 
with  these  formats  extends  the  usability  of  the  SFT. 

6.2.5  Memory  Size  In  the  current  program,  all  data  of  the  source/target  scenario  and  TP 
are  stored  in  computer  memory.  The  required  memory  size  is  described  in  Section  4.2.  The 
potential  problem  is  an  out-of-memory  exception.  Memory  size  is  not  a  big  problem  in  this 
area  since  we  can  increase  computer  memory  relatively  inexpensively.  However,  we  need  to 
consider  the  possibility  that  the  memory  is  not  sufficient  to  store  the  whole  data  of  a  scenario 
which  has  a  hundred  thousand  entities,  or  a  million  entities,  or  a  billion  entities  in  extreme 
cases.  Of  course,  there  are  several  techniques  to  solve  this  problem.  The  more  we  minimize 
the  required  memory  size,  the  more  the  SFT  is  stable.  One  of  the  ways  to  minimize  the 
required  memory  size  is  to  optimize  the  TP  data  structure.  When  we  determine  the  best  size 
of  each  variable,  we  can  reduce  the  TP  memory  size.  When  the  memory  is  not  enough  even 
after  optimizing  the  data  structure,  another  way  is  to  use  a  hard  disk  drive  to  temporarily  save 
current  state  of  the  TP. 

6.3  Conclusion 

This  thesis  effort  produces  a  system  which  translates  scenarios  of  one  format  to  scenarios  of  a 
different  format  in  order  to  increase  interoperability  between  simulations.  Although  this 
thesis  effort  concentrated  on  three  specific  simulations  ModSAF,  EADSIM  and 
BATTLESIM,  this  work  can  also  be  applied  to  other  simulations,  and  that  task  is  simplified 
by  the  TP. 
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Appendix  A.  Transitional  Scenario  File  Prototype 


A.1  ModSAF 


Table  A.  1  ModSAF  Transitional  Prototype 


Type 

Variable  Name 

Remark 

PO  FILE  HDR  * 

ms  hdr 

Structure  pointer 

PO_nLE_ENTRY 

ms_fe 

void  * 

msclass 

address  pointer 

PO_FILE_HDR,  PO_FILE_EN TRY  :  refer  to  ModSAF  source  code  ‘p_po.h’ 
A.2  EADSIM 

A.2.1  EADSIM  Scenario  File 

Table  A.2  EADSIM  ‘Scenario  File’  Transitional  Prototype 


Type 

Variable  Name 

Remark 

esheader  * 

ES  HeaderAddr 

Structure  pointer 

es  laydownfile  * 

ES  LaydownFileAddr 

structure  pointer 

es_elementmap  * 

ES_ElementMapAddr 

structure  pointer 

es  networkfile  * 

ES  NetworkfileAddr 

Structure  pointer 

es  zerothrumaxhost  * 

ES_ZeroThruMaxHostAddr 

structure  pointer 

es  unusedstring  * 

ES_UnusedStringAddr 

structure  pointer 

es  degug  * 

ES  DebugAddr 

structure  pointer 

es_host  * 

ES  HostAddr 

structure  pointer 

es_maxfilec3ioutput  * 

ES  MaxFileC3IOutputAddr 

structure  pointer 

es  truth  * 

ES  TmthAddr 

structure  pointer 

es_spds  * 

ES_SPDSAddr 

structure  pointer 

es  log  * 

ES  LogAddr 

structure  pointer 

es_stat  * 

ES  StatAddr 

structure  pointer 

es_pstat  * 

ES_PStatAddr 

structure  pointer 

es  file  * 

ES  FileAddr 

structure  pointer 

es  earthradadj  * 

ES  EarthRadAdjAddr 

structure  pointer 

es  hzululocal  * 

ES_  HZuluLocal  Addr 

1  structure  pointer 

ES  DisplayThruRouteAddr 

structure  pointer 

es  formatthrustarting  ♦ 

ES  FormatThruStartingAddr 

structure  pointer 

es  process  * 

ES  ProcessAddr 

structure  pointer 

es  write  * 

ES_WriteAddr 

structure  pointer 

es  cSilog  * 

ES  C3ILogAddr 

structure  pointer 

es  image  * 

ES_  ImageAddr 

structure  pointer 

es  transradfilepath  * 

ES  TransRadFilePathAddr 

structure  pointer 

es  time  * 

ES  TimeAddr 

Structure  pointer 

es  extemal  * 

ES_ExtemalAddr 

structure  pointer 

es  tb  * 

ES  TBAddr 

Structure  pointer 
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Table  A.3  EADSIM  ‘es  filename’  data  structure 


Type 

Variable  Name 

Remark 

char 

FileName 

String  size :  79 

es  filename  * 

NextFileNameAddr 

structure  pointer 

Table  A.4  EADSIM  ‘es  header’  data  structure 


Type 

Variable  Name 

Remark 

char 

Version 

string  size :  79 

char 

Tide 

string  size :  79 

int 

StartTime 

int 

EndTime 

int 

Interval 

unsigned  long  int 

MaxDuration 

Table  A.5  EADSIM  ‘es_laydownfile’  data  structure 


Type 

Variable  Name 

Remark 

int 

NumLaydowns 

es  filename  * 

NextFileNameAddr 

structure  pointer 

Table  A.6  EADSIM  ‘es_elementmap’  data  structure 


Type 

Variable  Name 

Remark 

char 

ElementPath 

string  size :  79 

char 

MapPath 

string  size  :  79 

Table  A.7  EADSIM  ‘es_networkfile’  data  structure 


Type 

Variable  Name 

Remark 

int 

NumNetworkFile 

string  size :  79 

es_filename  * 

NextFileNameAddr 

structure  pointer 
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Table  A.8  EADSIM  ‘es_zerothruniaxhost’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

Zero 

value ;  0 

char 

AOIPath 

stringsize :  79 

unsigned  char 

HOSTILE  SEE  HOSTILE 

boolean 

unsigned  char 

FRIENDLY  SEE  FRIENDLY 

boolean 

xmsigned  char 

MAX  HOST 

value :  8 

Table  A.9  EADSIM  ‘es_unusedstring’  data  structure 


Type 

Variable  Name 

Remark 

char 

UnusedStringO 

string  size :  79 

char 

UnusedStringl 

string  size :  79 

char 

UnusedString2 

string  size :  79 

char 

UnusedStringS 

string  size :  79 

char 

UnusedString4 

string  size :  79 

char 

UnusedString5 

String  size :  79 

char 

UnusedString6 

string  size ;  79 

char 

UnusedString? 

string  size :  79 

Table  A.  10  EADSIM  ‘es_debug’  data  structure 


Type 

Variable  Name 

Remark 

int 

Debug  FP 

int 

Debug_C3I 

int 

Debug  DET 

int 

Debug  PROP 

int 

Debug  GRF 

int 

Debug  NAM 

int 

Debug  ALSP 

int 

Debug  TB 
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Table  A.  1 1  EADSIM  ‘es  host’  data  structure 


Type 

Variable  Name 

Remark 

char 

Host  FP 

string  size :  79 

char 

Host  C3I 

string  size :  79 

char 

Host  DEI 

string  size :  79 

char 

Host  PROP 

string  size :  79 

char 

Host  GRF 

string  size :  79 

char 

Host  NAM 

string  size :  79 

char 

Host  ALSP 

string  size :  79 

char 

Host_TB 

string  size ;  79 

Table  A.  12  EADSIM  'es_maxfilec3ioutput’  data  structure 


-  . Type 

Variable  Name 

Remark 

unsigned  char 

MAX  FILE 

value :  40 

char 

CSIOutputPath 

string  size :  79 

Table  A,  13  EADSIM  ‘es  truth’  data  structure 


Type 

Variable  Name 

Remark 

char 

CSITruthFUe 

string  size :  79 

char 

FPTruthFile 

string  size :  79 

char 

PropagationTruthFile 

string  size :  79 

char 

DetectionTruthFile 

string  size :  79 

Table  A.  14  EADSIM  ‘es^spds’  data  structure 


Type 

Variable  Name 

Remark 

char 

C3ISPDSFile 

string  size :  79 

char 

DetectionSPDSFile 

string  size :  79 
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Table  A,  15  EADSIM  ‘es_log’  data  structure 


Type 

Variable  Name 

Remark 

char 

C3IL0GFile 

string  size :  79 

char 

FPLOGFile 

string  size ;  79 

char 

PropagationLOGFile 

string  size ;  79 

char 

DetectionLOGFile 

string  size :  79 

Table  A.  16  EADSIM  ‘es  stat’  data  structure 


Type 

Variable  Name 

Remark 

char 

C3ISTATFile 

string  size :  79 

char 

FPSTATFile 

string  size :  79 

char 

PropagationSTATFile 

string  size :  79 

Table  A.  17  EADSIM  ‘es_pstat’  data  structure 


Type 

Variable  Name 

Remark 

char 

C3IPSTATFile 

string  size :  79 

char 

DetectionPSTATFile 

string  size :  79 

char 

FPPSTATFUe 

String  size :  79 

char 

PropagationPSTATFile 

string  size :  79 
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Table  A.  18  EADSIM ‘es  file’ data  structure 


Type 

Variable  Name 

Remark 

char 

TIMESLOTFile 

String  size :  79 

char 

MSGDATAFile 

string  size ;  79 

char 

C3IENGSTATFile 

string  size ;  79 

char 

C3ICOMMSTATFile 

string  size ;  79 

char 

C3ITRACKSTATFile 

string  size :  79 

char 

FPSTATHEADERFile 

string  size :  79 

char 

COMMREQFile 

string  size :  79 

char 

CONSTATFile 

string  size :  79 

char 

ASSETFile 

string  size :  79 

char 

DetectionSTATFile 

string  size :  79 

char 

DetectionDEBUGFile 

string  size :  79 

char 

MEZFile 

string  size :  79 

char 

FPOutputPath 

String  size :  79 

char 

DetectionOutputPath 

string  size :  79 

char 

PropagationOutputPath 

string  size :  79 

char 

C3IINTELSTATFile 

1  string  size  :  79 

char 

C3IBASESTATFile 

string  size :  79 

char 

C3IlFFSTATFile 

string  size :  79 

char 

FPEVENTFile 

string  size :  79 

char 

C3IJAMSTATFile 

string  size :  79 

char 

PREFLYTBMFile 

String  size :  79 

char 

C3IRSRCSTATFile 

string  size :  79 

Table  A.  19  EADSIM  ‘es  earthradadj’  data  structure 


Type 

Variable  Name 

Remark 

float 

RadarEarthRadAdj 

float 

SigIntEarthRadAdj 

float 

1  . . 

float 

ImintEarthRadAdj 

float 

IRLEarthRadAdj 

float 

Table  A.20  EADSIM  ‘es  hzululocal’  data  structure 


Type 

Variable  Name 

Remark 

int 

HStart 

int 

Zulustart 

int 

LocalStart 
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Table  A.21  EADSIM  ‘es_displaythruroute’  data  structure 


Type 

Variable  Name 

Remark 

char 

DisplayPreFile 

string  size :  79 

char 

ColorPreFile 

String  size :  79 

char 

LLTRFile 

string  size :  79 

char 

RouteFile 

string  size ;  79 

Table  A.22  EADSIM  ‘es  formatthrustarting’  data  structure 


Type 

Variable  Name 

Remark 

int 

FormatSPDS 

int 

JammerOnTime 

Not  used 

int 

FractionPropUpdate 

int 

Socket  MAXSOCKET 

int 

TotalRuns 

int 

RunsToMake 

int 

StartingRun 

Table  A.23  EADSIM  ‘esjjrocess’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

FP  PROCESS 

boolean 

xmsigned  char 

C3I  PROCESS 

boolean 

unsigned  char 

DET  PROCESS 

boolean 

unsigned  char 

PROP  PROCESS 

boolean 

unsigned  char 

SGEN  PROCESS 

boolean 

unsigned  char 

NAM  PROCESS 

boolean 

unsigned  char 

ALSP  PROCESS 

boolean 

unsigned  char 

DIS  PROCESS 

boolean 

unsigned  char 

TB  PROCESS 

boolean 

unsigned  char 

SEEDFROMPREVIOUS 

boolean 
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Table  A.24  EADSIM  ‘es  write’  data  structure 


- . . Type 

Variable  Name 

Remark 

unsigned  char 

WRITE  PROP  LOG 

boolean 

unsigned  char 

WRITE  PROP  STAT 

boolean 

unsigned  char 

WRITE  PROP_PSTAT 

boolean 

unsigned  char 

WRITE  DET  SPDS 

boolean 

unsigned  char 

WRITE  LOG 

boolean 

unsigned  char 

WRITE  DET  STAT 

boolean 

unsigned  char 

WRITE  DET  PSTAT 

boolean 

unsigned  char 

WRITE  DET  DEBUG 

boolean 

unsigned  char 

WRITE  C3I  LOG 

boolean 

unsigned  char 

WRITE  C3I  PSTAT 

boolean 

unsigned  char 

WRITE  ENGSTAT 

boolean 

unsigned  char 

WRITE  IFFSTAT 

boolean 

unsigned  char 

WRITE.  COMMSTAT 

boolean 

unsigned  char 

WRITE  TRACKSTAT 

boolean 

unsigned  char 

WRITE  INTELSTAT 

boolean 

unsigned  char 

WRITE  BASESTAT 

boolean 

unsigned  char 

WRITE  JAMSTAT 

boolean 

unsigned  char 

WRITE  PSRCSTAT 

boolean 

unsigned  char 

WRITE  TRUTH 

boolean :  TRUE 

unsigned  char 

WRITE  FP  LOG 

boolean 

unsigned  char 

WRITE  FP  PSTAT 

boolean 

unsigned  char 

WRITE  STATHDR 

boolean :  TRUE 

Table  A.25  EADSIM  ‘es_c3iIog’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

WRITE  FPEVENTS 

boolean 

unsigned  char 

C3ILog  PLAT  STATUS 

boolean 

unsigned  char 

C3ILog  MSG  CONFIRM 

boolean 

unsigned  char 

C3ILog  PHASE  STATS 

boolean 

unsigned  char 

C3ILog  UTIL  STATS 

boolean 

unsigned  char 

C3ILog  MSG  HANDLER 

boolean 

unsigned  char 

C3ILog  TRACK  HANDL 

boolean 

unsigned  char 

C3ILog  ENG  EVENTS 

boolean 

unsigned  char 

C3ILog  SPDS  INFO 

boolean 

unsigned  char 

C3ILog  MISL  DETECT 

boolean 

unsigned  char 

C3ILog  COMM  CHECKS 

boolean 

unsigned  char 

C3ILog  IFF  MSGS 

boolean 

unsigned  char 

C3ILog  RSRC  EVENTS 

boolean 

imsigned  char 

C3rLog  SENSOR  MAN 

boolean 

unsigned  char 

LOG  ALL  NET  STATS 

boolean 

float 

NetStatsInterval 

boolean 

Table  A. 26  EADSIM  ‘es_iiiiage’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

DIED  IMAGE 

unsigned  char 

ADRG  IMAGE 

unsigned  char 

NO  IMAGE 

unsigned  char 

1 :  Overview  3  ;  Map  Image 

float 

ADRGMapNLat 

float 

ADRGMapSLat 

float 

ADRGMapWLon 

float 

ADRGMapELon 

unsigned  char 

ADRG  USE  CDROM  ASPECT 

unsigned  char 

ADRGImageSource 

l.'Read  from  file  2:from  CDROM 

char 

ADRGImagePath 

string  size ;  79 

Table  A.27  EADSIM  ‘esjransradfilepath’  data  structure 


Type 

Variable  Name 

Remark 

char 

TransmissionFilePath 

string  size :  79 

char 

RadianceFilePath 

string  size :  79 

Table  A.28  EADSIM  ‘es_defaultsentiine’  data  structure 


Variable  Name 

Remark 

int 

DefeultSenOnTime 

int 

DefaultSenOflTime 

es  defaultsentime  * 

ES  NextDefaultSenTimeAddr 

structure  pointer 

Table  A.29  EADSIM  ‘es_defaultjamtime’  data  structure 


Type 

Variable  Name 

Remark 

int 

DefaultJamOnTime 

int 

DefaultJamOfirrime 

es  defaultjamtime  * 

ES  NextDefaultJamTimeAddr 

Structure  pointer 

A-9 


Table  A.30  EADSIM  ‘es  totalnins’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  int 

RSeedC3I 

unsigned  int 

RSeedDetect 

es  totalnins  * 

ES_NextTotaIRuiisAddr 

structure  pointer 

Table  A.31  EADSIM  ‘es  time’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  int 

NumGlobalSensorTime 

es_defaultsentime  * 

ES  NextDefaultSenTimeAddr 

structure  pointer 

unsigned  int 

NumGlobaUainmerTimes 

es  defaultjamtime  * 

ES_NextDefaultJamTimeAddr 

structure  pointer 

es  totalnins  * 

ES  NextTotalRunsAddr 

structure  pointer 

Table  A.32  EADSIM  ‘es  external’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  int 

ALSPAddress  ConfedID 

unsigned  int 

ALSP Address  ActorlD 

char 

ALSPAddress  ACMHostName 

string  size  :  79 

unsigned  int 

DISAddress  Site 

unsigned  int 

DISAddress  Host 

int 

BCastInPort 

int 

BCastOutPort 

char 

Netlnterface 

string  size :  25 

int 

ExerciselD 

float 

AirTimeOut 

float 

GndTimeOut 

double 

AirThreshold 

double 

GndThreshold 

unsigned  char 

MSL  LAUNCH  PROCESS 
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Table  A.33  EADSIM  ‘es  tb’  data  structure 


Type 

Variable  Name 

Remark 

char 

TBAddress  HostMachine 

string  size :  25 

char 

TBAddress  ExePath 

string  size :  254 

char 

TBAdciress_  OutPath 

string  size :  254 

char 

TBAddress  Datapath 

string  size :  254 

char 

TBAddress  CmdLine 

string  size :  1024 

unsigned  int 

TBAddress  Site 

unsigned  int 

TBAddress  Host 

unsigned  char 

EXT  REAL  TIME 

unsigned  char 

TIME  REGULATING 

unsigned  char 

TIME  CONSTRAINED 

imsigned  char 

START  TB 

unsigned  char 

PREFLYTBM 

float 

EMCONLat 

float 

EMCONLon 

A2.2  EADSIM  Laydown  File 


Table  A.34  EADSIM  ‘es_lay’  data  structure 


- lipe 

Variable  Name 

Remark 

char 

Version 

string  size :  25 

int 

NumPlatforms 

esjayplatform  ♦ 

ES  NextLayPlatformAddr 

structure  pointer 

A-11 


Table  A.35  EADSIM  ‘es_layplatfonn’  data  structure 


Type 

Variable  Name 

Remark 

char 

MillD 

string  size :  25 

char 

SystemE) 

string  size ;  25 

char 

ConunanderlD 

string  size :  25 

int 

Colorindex 

esjaysensor  * 

ES_NextLaySensorAddr 

Structure  pointer 

int 

NumComDevs 

eslaycomdev  * 

ES  NextLayComDevAddr 

structure  pointer 

ES_NextLayJammerAddr 

structure  pointer 

int 

NumAssets 

esjayasset  * 

ES  NextLayAssetAddr 

Structure  pointer 

int 

NumTargets 

es  laytarget  * 

ES  NextLayTargetAddr 

structure  pointer 

int 

NumlFTUPlatfonns 

esjayiftuplatfomi  * 

ES  NextLaylFTUPlatformAddr 

structure  pointer 

unsigned  char 

SIM 

boolean 

imsigned  char 

HHOUR 

boolean 

unsigned  char 

LOCAL 

boolean 

unsigned  char 

ZULU 

boolean 

unsigned  char 

HM  NO  DELIM 

boolean 

unsigned  char 

HMS 

boolean 

unsigned  char 

AS  ENTERED 

boolean 

char 

TimeSuflSx 

string  size :  25 

unsigned  char 

LOG_TRACK  EVENT 

unsigned  char 

LASER  ABSOLUTE 

float 

LaserRestAz 

float 

LaserRestEl 

unsigned  char 

PlatformType 

eslayplatformsatellite  * 

ES  LayPlatformSatelliteAddr 

Structure  pointer 

unsigned  char 

UseRouteData 

boolean 

usjayuseroutedata  * 

ES  LayUseRouteDataAddr 

Structure  pointer 

us  laynotuseroutedata  * 

ES  LayNotUseRouteDataAddr 

structure  pointer 

int 

NumPTLs 

esjayptl  * 

ES  NextLayPTLAddr 

structure  pointer 

int 

NumLCS 

esjaytnilid  * 

ES  NextLayLCSAddr 

structure  pointer 

int 

NumDecoys 

eslaymilid  * 

ES  NextLayDecoyAddr 

structure  pointer 

int 

NumSurvPlat 

es  laymilid  * 

ES  NextLaySurvAddr 

structure  pointer 

unsigned  char 

CMData 

boolean 

unsigned  char 

EMCOM  DEFAULT 

boolean 

int 

EMCOMAuthority 

eslayplatfomiaircraft  * 

ES  LayPlatformAircraft 

unsigned  char 

AIRBASE 

boolean 

es_layplatformairbase  * 

ES  LayPlatformAirBaseAddr 

Structure  pointer 

es  layplatform  * 

ES NextLayPlatformAddr 

structure  pointer 

Table  A.36  EADSIM  ‘es_laysensor’  data  structure 


Type 

Variable  Name 

Remark 

int 

NumSensors 

es  laysensorheader  * 

ES  NextlaySensorHeaderAddr 

structure  pointer 

int 

NumTimings 

int 

NnmTimes 

esjaytime  * 

ES_NextlayTimeAddr 

structure  pointer 

Table  A.37  EADSIM  ‘es_laysensorheader’  data  structure 


Type 

Variable  Name 

Remark 

char 

Name 

string  size :  25 

int 

AntHeight 

float 

VerAngle 

float 

HorAngle 

float 

Lat 

float 

Lon 

float 

Alt 

unsigned  char 

PtMode 

float 

NomFreq 

char 

ToPlatform 

string  size :  25 

unsigned  char 

DEFAULT  ANTHEIGHT 

boolean 

unsigned  char 

DEFAULT  HORANGLE 

boolean 

unsigned  char 

DEFAULT  VERANGLE 

boolean 

unsigned  char 

DEFAULT  PTMODE 

boolean 

unsigned  char 

DEFAULT  TIMING 

boolean 

unsigned  char 

DEFAULT  FREQ 

boolean 

int 

NumSensorPointings 

es  laypointing  * 

ES  NextLayPointingAddr 

structure  pointer 

eslaysensorheader  * 

ES_NextLaySensorHeaderAddr 

structure  pointer 
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Table  A.38  EADSIM  ‘es_laycomdev’  data  structure 


Type 

Variable  Name 

Remark 

char 

Name 

string  size ;  25 

int 

AntHeight 

float 

VerAngle 

float 

HorAngle 

float 

Lat 

float 

Lon 

float 

Alt 

unsigned  char 

PtMode 

char 

ToPlatform 

String  size :  25 

unsigned  char 

DEFAULT  ANTHEIGHT 

boolean 

unsigned  char 

DEFAULT  HORANGLE 

boolean 

unsigned  char 

DEFAULT  VERANGLE 

boolean 

unsigned  char 

DEFAULT  FIMODE 

boolean 

es  laycomdev  * 

ES  NextLayComDevAddr 

Structure  pointer 

Table  A.39  EADSIM  ‘es_layjanuner’  data  structure 


Table  A.40  EADSIM  ‘es  layjammerheader’  data  structure 


Type 

Variable  Name 

char 

Name 

int 

Number 

int 

AntHeight 

float 

VerAngle 

float 

HorAngle 

float 

Lat 

float 

Lon 

float 

Alt 

imsigned  char 

PtMode 

char 

ToPlatform 

unsigned  char 

DEFAULT  ANTHEIGHT 

imsigned  char 

DEFAULT  HORANGLE 

unsigned  char 

DEFAULT  VERANGLE 

unsigned  char 

DEFAULT  PTMODE 

unsigned  char 

DEFAULT  TIMING 

int 

NumJammerPointings 

es  laypointing* 

ES  NextLayPointingAddr 

esjayjammerheader  * 

ES  NextLayJammerHeaderAddr 

Remark 
string  size :  25 
Not  used 


boolean 

boolean 

boolean 

boolean 

boolean 


structure  pointer 


Table  A.41  EADSIM  ‘es_layasset’  data  structure 


Type 

Variable  Name 

char 

Name 

int 

Priority 

float 

ThreatRangeCEN 

float 

CriticalRangeCEN 

float 

ThreatRangeDECEN 

float 

CriticalRangeDECEN 

float 

DownRangeCEN 

float 

CrossRangeCEN 

float 

DownRangeDECEN 

float 

CrossRangeDECEN 

imsigned  char 

CEN  ABT  SELF 

unsigned  char 

CEN  ABT  SUBORD 

unsigned  char 

CEN  ABT  CMDR 

unsigned  char 

CEN  ABT  ASSET 

unsigned  char 

CEN  ABT  SUBSUBORD 

unsigned  char 

CEN  ABT  SUBASSET 

unsigned  char 

CEN  ABT  ZONE 

unsigned  char 

DECEN  ABT  SELF 

unsigned  char 

DECEN  ABT  SUBORD 

unsigned  char 

DECEN  ABT  CMDR 

unsigned  char 

DECEN  ABT  ASSET 

unsigned  char 

DECEN  ABT  SUBSUBORD 

unsigned  char 

DECEN  ABT  SUBASSET 

unsigned  char 

DECEN  ABT  ZONE 

tmsigned  char 

DEFEND  TM 

unsigned  char 

CEN  TM  SELF 

imsigned  char 

CEN  TM  SUBORD 

unsigned  char 

CEN  TM  CMDR 

unsigned  char 

CEN  TM  ASSET 

unsigned  char 

CEN  TM  SUBSUBORD 

unsigned  char 

CEN  TM  SUBASSET 

unsigned  char 

CEN  TM  ZONE 

unsigned  char 

DECEN  TM  SELF 

unsigned  char 

DECEN  TM  SUBORD 

unsigned  char 

DECEN  TM  CMDR 

unsigned  char 

DECEN  TM  ASSET 

unsigned  char 

DECEN  TM  SUBSUBORD 

unsigned  char 

DECEN  TM  SUBASSET 

unsigned  char 

DECEN  TM  ZONE 

unsigned  char 

DEFEND  ABT 

es  layasset* 

ES  NextLayAssetAddr 

Remark 
string  size :  25 


boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

boolean _ 

structure  pointer 
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Table  A.42  EADSIM  ‘es_laytarget’  data  structure 


.  . Type 

Variable  Name 

Remark 

char 

Name 

String  size :  25 

int 

Priority 

int 

LaunchTime 

int 

WPNumber 

char 

Weapon 

string  size :  25 

char 

CaptivePlatform 

string  size ;  25 

float 

LauchDelay 

unsigned  char 

TARGET  REQDETECT 

boolean 

float 

HOB 

ES  NextLayTargetAddr 

structure  pointer 

Table  A.43  EADSIM  ‘es_layiftuplatform’  data  structure 


.Type 

Variable  Name 

Remark 

char 

Name 

string  size :  25 

es  layiftuplatform  * 

ES  NextLaylFTUPlatformAddr 

Structure  pointer 

Table  A.44  EADSIM  ‘es  layplatformsatellite’  data  structure 


Type 

Variable  Name 

Remark 

float 

X 

float 

Y 

float 

Z 

float 

XDot 

float 

YDot 

float 

ZDot 

float 

InitialTime 

float 

InitialLon 
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Table  A.45  EADSIM  ‘es_layuseroutedata’  data  stracture 


Type 

Variable  Name 

Remark 

char 

RouteName 

String  size :  25 

float 

ActivationTime 

float 

ActivationTimeDt 

Table  A.46  EADSIM  ‘esjaynotuseroutedata’  data  structure 


Type 

Variable  Name 

Remark 

int 

NumWayPoints 

imsigned  char 

WpMode 

ES  NextLayNURDWayPointAddr 

structure  pointer 

Table  A.47  EADSIM  ‘esjayptl’  data  structure 


Type 

Variable  Name 

Remark 

int 

PTLOnTime 

float 

PTL  Azimuth 

es  layptl  * 

ES  NextLayPTLAddr 

Structure  pointer 

Table  A.48  EADSIM  ‘es_layacfrc’  data  structure 


Type 

Variable  Name 

Remark 

float 

RefuelAmount 

int 

NumTankers 

es  laymilid  * 

ES  NextLayMillDAddr 

Structure  pointer 
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Table  A.49  EADSIM  ‘es_laywaypoint’  data  structure 


Type 

Variable  Name 

Remark 

float 

Lat 

float 

Lon 

float 

Alt 

unsigned  char 

Type 

char 

MilID 

string  size :  25 

unsigned  char 

TerrainFlag 

unsigned  char 

Zmode 

float 

Speed 

int 

OnTime 

int 

OfifTime 

es_laywaypoint  * 

ES_NextLayWayPointAddr 

structure  pointer 

Table  A.50  EADSIM  ‘es  layart’  data  structure 


Type 

Variable  Name 

Remark 

int 

NumWayPoints 

ES_NextLayWaypointAdcir 

Structure  pointer 

Table  A.5 1  EADSIM  ‘esjayplatformaircraft’  data  structure 


Type 

Variable  Name 

Remark 

char 

FlightLeader 

string  size :  25 

char 

HomeAirbaselD 

string  size :  25 

int 

AlertLevel 

unsigned  char 

AtBaseFlag 

unsigned  char 

FLIGHT  REFILL 

boolean 

int 

DeactivationTime 

unsigned  char 

FLIGHT  REFUEL  CAPABLE 

boolean 

es  layacfrc* 

ES  LayACFRCAddr 

1  structure  pointer 

unsigned  char 

AIRREFUELTANKER 

boolean 

es_layart  * 

ES  LayACARTAddr 

structure  pointer 
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Table  A.52  EADSIM  ‘esjayplatfonnairbase’  data  structure 


Type 

Variable  Name 

Remark 

float 

Radius 

float 

RunWayArea 

float 

TumArea 

float 

C2Area 

float 

AC  PK 

float 

TOIntervalPenalty 

int 

TumDelay 

int 

DelayFirstlmpact 

int 

MinTakeOfflnterval 

int 

TOPenaltyExp 

int 

TBMpriority 

int 

DCApriority 

int 

GAPpriority 

int 

int 

MaxTBMReq 

int 

MaxDCAReq 

int 

MaxGAReq 

Table  A.53  EADSIM  ‘es_laymilid’  data  structure 


Type 

Variable  Name 

Remark 

char 

MillD 

string  size :  25 

es  laymilid  * 

ES_NextLayMilIDAddr 

Structure  pointer 

Table  A.54  EADSIM  ‘esjaytime’  data  structure 


Type 

Variable  Name 

Remark 

int 

OnTime 

int 

OfifTime 

es  laytime  * 

ES  NextlayTimeAddr 

structure  pointer 
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Table  A.55  EADSIM  ‘es  laypointing’  data  structure 


Type 

Variable  Name 

Remark 

char 

ToPlatform 

string  size ;  25 

int 

OnTime 

int 

OfFTime 

int 

AntHeight 

float 

VerAngle 

float 

HorAngle 

unsigned  char 

PtMode 

ES_NextLayPointingAddr 

1  Structure  pointer 

Table  A.56  EADSIM  ‘es_laynurdwaypoint’  data  structure 


Type 

Variable  Name 

Remark 

float 

Lat 

float 

Lon 

float 

Alt 

unsigned  char 

Type 

chat 

MilID 

string  size ;  25 

unsigned  char 

TerrainFlag 

boolean 

unsigned  char 

Zmode 

boolean 

float 

Speed 

int 

OnTime 

int 

OfiTTime 

ES  NextLayNURDWayPointAddr 

Structure  pointer 

Table  A.57  EADSIM  ‘es_layaircraftdata’  data  structure 


Type 

Variable  Name 

Remark 

char 

Name 

string  size :  25 

imsigned  char 

Domain 

Enumeration  Type 

unsigned  int 

Country 

Enumeration  Type 

unsigned  char 

Category 

Enumeration  Type 

unsigned  char 

SubCategory 

Enumeration  Type 

unsigned  char 

Specific 

Enumeration  Type 
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A.S  BATTLESIM 


Table  A.58  BATTLESIM  ‘bs_scenario’  data  structure 


Type 

Variable  Name 

Remark 

BS_Header 

Header 

structure 

bs  object* 

NextObjAddr 

Structure  pointer 

Table  A.59  BATTLESIM  ‘BS_TerrainMmCoord’  data  structure 


Type 

Variable  Name 

Remark 

double 

xmin 

double 

double 

zmin 

Table  A.  60  BATTLESIM  ‘BS  TerrainMaxCoord’  data  structure 


Type 

Variable  Name 

Remark 

double 

xmax 

double 

double 

zmax 

Table  A.6I  BATTLESIM  ‘bs  sector’  data  structure 


Type 

Variable  Name 

Remark 

double 

xmin 

double 

double 

zmin 

double 

xmax 

double 

double 

zmax 

bs  sector  * 

NextSectorAddr 

Structure  pointer 

A -21 


Table  A.62  BATTLESIM  ‘bs  icon’  data  structure 


Type 

Variable  Name 

Remark 

int 

IconNumber 

char 

IconName 

string  size :  20 

bs  icon  * 

NextIconAddr 

Structure  pointer 

Table  A.  63  BATTLESIM  ‘BSJHeader’  data  structure 


Type 

Variable  Name 

Remark 

char 

VersionNumber 

String  size :  20 

char 

TerrainFileName 

string  size ;  50 

BS  TerrainMinCoord 

TerrainMinCoord 

Structure 

BS  TerrainMaxCoord 

TerrainMaxCoord 

structure 

int 

NumSectors 

bs  sector* 

NextSectorAddr 

structure  pointer 

int 

Numlcons 

bsjcon  * 

NextIconAddr 

Structure  pointer 

Table  A.64  BATTLESIM  ‘bs_object’  data  structure 


Type 

Variable  Name 

Remark 

BS_DescObj 

DescObj 

structure 

int 

NumRoutePoints 

bs.  routepoint  * 

NextRoutePoints 

structure  pointer 

int 

NumSensors 

bs  sensor* 

NextSensorAddr 

structure  pointer 

int 

NumArmaments 

bs  armament  * 

NextArmamentAddr 

structure  pointer 

int 

NumTargets 

bs_target  * 

NextTargetAddr 

structure  pointer 

int 

NumDefensiveSys 

bs_defensive  * 

NextDefensiveSysAddr 

structure  pointer 

bs  object  * 

NextObjAddr 

structure  pointer 

Table  A.65  BATTLESIM  ‘BS_ObjectLocation’  data  structure 


Type 

Variable  Name 

Remark 

double 

xcoord 

double 

ycoord 

double 

zcoord 
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Table  A.66  BATTLESIM  ‘BS_ObjectVelocity’  data  structure 


Type 

Variable  Name 

Remark 

double 

xvel 

double 

yvel 

double 

zvel 

Table  A.67  BATTLESIM  ‘BS  ObjectOrientation’  data  structure 


Type 

Variable  Name 

Remark 

double 

yawrate 

double 

pitchrate 

double 

rollrate 

Table  A.68  BATTLESIM  ‘BS_DescObj’  data  structure 


Type 

Variable  Name 

Remark 

int 

ObjectType 

Enumeration  Type 

int 

ObjectID 

double 

CurrentTime 

BS_ObjectLocation 

ObjectLoc 

structure 

BS  ObjectVelocity 

ObjectVel 

Structure 

BS__ObjectOrientation 

ObjectOri 

structure 

double 

PlayerSize 

double 

mass 

int 

ObjectLoyalty 

int 

FuelStat 

int 

Condition 

int 

Vulnerability 

int 

Experience 

int 

ThreatKnow 

int 

MinTumRad 

int 

MaxSpeed 

int 

AvgFuelCons 

int 

MaxClimb 
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Table  A.69  BATTLESIM  ‘bs  routepoint’  data  structure 


Type 

Variable  Name 

Remark 

double 

xcoord 

double 

ycoord 

double 

zcoord 

bs  routepoint  * 

NextRoutePointAddr 

Structure  pointer 

Table  A.70  BATTLESIM  ‘bs  sensor’  data  structure 


Type 

Variable  Name 

Remark 

int 

SensorType 

int 

SensorRange 

int 

SensorResolution 

bssensor  * 

NextSensorAddr 

Structure  pointer 

Table  A.71  BATTLESIM  ‘bs_armament’  data  structure 


Type 

Variable  Name 

Remark 

int 

ArmamentType 

int 

ArmamentRange 

int 

ArmamentYield 

int 

ArmamentAccuracy 

int 

ArmamentSpeed 

int 

ArmamentCount 

bs  armament  * 

NextArmamentAddr 

structure  pointer 

Table  A.72  BATTLESIM  ‘bsjarget’  data  structure 


Type 

Variable  Name 

Remark 

int 

TargetType 

double 

TargetXCoord 

double 

TargetYCoord 

double 

TargetZCoord 

bs  target  * 

NextTargetAddr 

structure  pointer 
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Table  A.73  BATTLESIM  ‘bsjdefensive’  data  structure 


Type 

Variable  Name 

Remark 

int 

DefensiveSysType 

int 

DefensiveSysRange 

int 

DefensiveSysEfifect 

bs_defensive  * 

NextDefensiveSysAddr 

structure  pointer 

A.  4  Transitional  File 


Table  A.74  Transitional  File  ‘tf  transfile’  data  structure 


Type 

Variable  Name 

Remark 

char 

Version 

string  size :  25 

TF  NumEntities 

tf  database  * 

NextDatabaseAddr 

structure  pointer 

Table  ATS  Transitional  File  ‘tf_database’  data  structure 


Type 

Variable  Name 

Remark 

tf  entityheader  * 

TF  EntityHeaderAddr 

structure  pointer 

tf_entitytype  * 

TF  EntitytTypeAddr 

structure  pointer 

tf  entitylocation  * 

TF_EntityLocationAddr 

structure  pointer 

tf  entityvelocity  * 

TF  EntityVelocityAddr 

structure  pointer 

tf entityorientation  * 

TF  EntityOrientationAddr 

structure  pointer 

unsigned  char 

TF  NumKindMunitions 

tf  munitiontype  * 

NextMunitionAddr 

structure  pointer 

unsigned  char 

TF  NumSensors 

tf  sensorid  * 

NextSensorAddr 

Structure  pointer 

unsigned  char 

TF__NumJammers 

tf  jammerid  * 

NextJammerAddr 

structure  pointer 

unsigned  char 

TF  NumTasks 

tf  tasktype 

NextTaskAddr 

Structure  pointer 

tf  database  * 

NextDatabaseAddr 

structure  pointer 
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Table  A.76  Transitional  File  ‘tfjjoint’  data  structure 


Type 

Variable  Name 

Remark 

double 

LocationX 

double 

LocationY 

double 

LocationZ 

tf  point  * 

NextPointAddr 

Structure  pointer 

Table  A.77  Transitional  File  ‘tf  location’  data  structure 


Type 

Variable  Name 

Remark 

double 

LocationX 

double 

LocationY 

double 

LocationZ 

Table  A.78  Transitional  File  ‘tf_entityheader’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  int 

Entityld 

Enumeration  Type 

unsigned  char 

Forceld 

Enumeration  Type 

char 

EntityName 

String  size :  25 

Table  A.79  Transitional  File  ‘tf_entitytype’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

Domain 

Enumeration  Type 

unsigned  int 

Country 

Enumeration  Type 

unsigned  char 

Category 

Enumeration  Type 

unsigned  char 

SubCategory 

Enumeration  Type 

unsigned  char 

Specific 

Enumeration  Type 

Table  A.80  Transitional  File  ‘tf_entityvelocity’  data  structure 


Type 

Variable  Name 

Remark 

float 

VelocityX 

float 

VelocityY 

float 

VelocityZ 
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Table  A.  81  Transitional  File  ‘tf_entityorientation’  data  structure 


Type 

Variable  Name 

Remark 

float 

Psi 

float 

Theta 

float 

Phi 

Table  A.82  Transitional  File  ‘tf_munitiontype’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

Domain 

Enumeration  Type 

unsigned  int 

Country 

Enumeration  Type 

unsigned  char 

Category 

Enumeration  Type 

unsigned  char 

SubCategoiy 

Enumeration  Type 

unsigned  char 

specific 

Enumeration  Type 

unsigned  int 

Amoimt 

tf  munitiontype  * 

NextMunitionAddr 

structure  pointer 

Table  A.83  Transitional  File  ‘tf_sensorid’  data  structure 


Type 

Variable  Name 

Remark 

char 

SensorlD 

string  size :  25 

tf_sensorid  * 

NextSensorAddr 

structure  pointer 

Table  A.84  Transitional  File  ‘tfjammerid’  data  structure 


Type 

Variable  Name 

Remark 

char 

JammerlD 

string  size :  25 

tfjammerid  * 

NextJammerAddr 

Structure  pointer 

Table  A.85  Transitional  File  ‘tf  tasktype’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

TaskType 

Enumeration  Type 

void  * 

TaskDataAddr 

address  pointer 

tf_tasktype  * 

NextTaskAddr 

structure  pointer 
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Appendix  B.  Enumeration  Type  for  Task  Type  of  Transitional  Prototype 


B.1  Task  Name 

Field  Value  1-99  :  Ground  Mission 
Field  Value  100-149  :  Air  Mission 
100-124 :  FWA  Mission 
125-  149  :RWA  Mission 
Field  Value  150-199  :  Surface  Mission 
Field  Value  200-249  :  Space  Mission 
Field  Value  250-255  :  Extra 


Table  B .  1  Enumeration  Type  of  Task  Name 


Field  Value 

Task  Kind 

0 

Others 

1 

Move 

2 

Road  March 

3 

Follow  a  Vehicle 

4 

Follow  Simulator 

5 

Pursue 

6 

Hasty  Occupy  Position 

7 

Assault 

8 

Traveling  Overwatch 

9 

Overwatch  Movement 

10 

Withdraw 

11 

Breach 

12 

Attack  By  Fire 

13 

Concealment 

14 

Delay 

15 

Repair 

16 

Sevice  Station 

17 

Cross-leveling 

18 

Change  Formation 

19 

Rendezvous 

100 

FWA  Sweep 

101 

FWA  CAP 

102 

FWA  CAS  Mission 

103 

FWA  Ingress 

104 

FWA  Attack  Ground  Target 

B-1 


105 

FWA  Egress 

106 

FWA  Return  to  Base 

107 

FWA  Interdiction  Mission 

125 

RWA  Fly  Route 

126 

RWA  Hover 

127 

RWA  Orbit 

128 

RWA  Assemble 

129 

RWA  Attack 

130 

RWA  Hasty  Occupy  Position 

B.2  Data  Structures  for  Each  Task  Type 


Table  B.2  Task  ‘Move’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

unsigned  char 

TravelType 

Enumeration  Type 

unsigned  char 

Formation 

Enumeration  Type 

float 

RateOfMarch 

float 

CatchUpSpeed 

float 

DismountedSpeed 

unsigned  int 

FolIowingLeader 

unsigned  int 

FollowingLeaderDegree 

float 

FollowingLeaderDistance 

unsigned  char 

NumPoints 

LeftBoundary 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

RightBoundaiy 

tf  point  * 

PointAddr 

unsigned  char 

Spacing 

Enumeration  Type 

float 

float 

IFVOfifsetX 

float 

IFVOffsetY 

B.2.2 


I 

I 

i 


B.2.3 


Road  March 
same  as  Task  “Move”. 
Follow  a  Vehicle 
same  as  Task  “Move”. 


B-2 


B.2.4  Follow  Simulator 


Table  B.3  Task  ‘Follow  Simulator’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

SimulatorToFollow 

unsigned  char 

TravelType 

Enumeration  Type 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

Enumeration  Type 

float 

float 

RejoinSimDistance 

B.2.5  Pursue 

same  as  Task  “Move”. 


B.2,6  Hasty  Occupy  Position 

Table  B.4  Task  ‘Hasty  Occupy  Position’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

BattlePosition 

tf  joint  * 

PointAddr 

unsigned  char 

NumPoints 

EngagementArea 

tf  point  * 

PointAddr 

tf  location  * 

LeflTRP 

tf_  location  * 

RightTRP 

float 

Speed 

tf  location  * 

TriggerLine 

unsigned  char 

TriggerCriteria 

unsigned  char 

TriggerUnitSize 

unsigned  char 

NumPoints 

SecondaiyBattlePosition 

tf_point  * 

PointAddr 

unsigned  char 

NumPoints 

SecondaryEnggArea 

tf  joint  * 

PointAddr 

tf  location  * 

SecondaryLeftTRP 

tf  location  * 

SecondaryRightTRP 
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B.2. 7  Assault 


Table  B.5  Task  ‘Assault’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumObjectives 

Objectives 

tf  point  * 

ObjectivesAddr 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

float 

Speed 

float 

DismountedSpeed 

float 

StoppingAssaultCriteria 

unsigned  char 

SecureObjective 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

Spacing 

Enumeration  Type 

float 

UserSpecifiedSpacing 

float 

IFVOffsetX 

float 

IFVOfFsetY 

B.2.8  Traveling  Overwatch 

Table  B.6  Task  ‘Traveling  Overwatch’  data  structure 


Type 

Variable  Name 

Remark 

imsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

float 

RateOfMarch 

float 

CatchUpSpeed 

float 

SupportGroupFollowingDistance 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

Enumeration  Type 

float 

! 

unsigned  char 

ConformToTerrain 

boolean 

B.2.9  Ovenvatch  Movement 

Table  B.7  Task  ‘Overwatch  Movement’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

unsigned  char 

UseConcealedRoute 

boolean 

unsigned  char 

NumPoints 

LeftBoimdaiy 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

RightBoundaiy 

tf  point  * 

PointAddr 

unsigned  char 

Movement 

Enumeration  Type 

float 

RateOfMarch 
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float 

CatchUpSpeed 

float 

DismountedSpeed 

unsigned  int 

FollowingLeader 

unsigned  int 

FollowingLeaderDegree 

float 

FollowingLeaderDistance 

unsigned  char 

Spacing 

Enumeration  Type 

float 

UserSpecifiedSpacing 

unsigned  char 

Formation 

Enumeration  Type 

imsigned  char 

DIFormation 

float 

IFVOffsetX 

float 

IFVOffsetY 

B.2.10  Withdraw 


Table  B.8  Task  ‘Withdraw’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

unsigned  char 

Smoke 

Enumeration  Type 

float 

Speed 

float 

SpeedLimit 

B.2.11  Breach 


Table  B.9  Task  ‘Breach’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

unsigned  char 

CreateMarkers 

boolean 

float 

MaxDistBtwMarks 

float 

BreachLaneWidth 

B.2.12  Attack  By  Fire 

same  as  Task  “Hasty  Occupy  Position”. 
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B.2.13  Concealment 


Table  B.IO  Task  ‘Concealment’  data  structure 


-  -  Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point* 

PointAddr 

float 

Distance 

float 

RateOfMarch 

float 

FrontWidth 

unsigned  int 

ForwardSpread 

unsigned  int 

BackwardSpread 

B.2.14  Delay 


Table  B.  1 1  Task  ‘Delay’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

BattlePositionl 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

BattlePosition2 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

BattlePositionS 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

BattlePosition4 

tf  point* 

PointAddr 

float 

Speed 

B.2.15  Repair 


Table  B.12  Task  ‘Repair’  data  structure 


Type 

Variable  Name 

Remark 

tfjocation  * 

UMCPSite 

unsigned  char 

TowVehicle 

unsigned  char 

VehicleToRepair 

B.2.16  Sevice  Station 


Table  B.13  Task  ‘Service  Station’  data  structure 


- Type - 

Variable  Name 

Remark 

unsigned  char 

SupplyUnit 
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B.2.17  Cross-leveling 


Table  B.14  Task  ‘Cross  Leveling’  data  structure 


--  Type 

Variable  Name 

Remark 

tf  location  * 

CrossLevelingAreaLocation 

float 

CrossLevelingAreaRadius 

unsigned  char 

SupplyToCrossLevel 

B.2.18  Change  Formation 


Table  B.15  Task  ‘Change  Formation’  data  structure 


Type 

Variable  Name 

Remark 

tf  location  * 

Destination 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  int 

FormationAngle 

B.2.19  Rendezyous 


Table  B.16  Task  ‘Rendezvous’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

Partner 

tf  location  * 

Objective 

unsigned  char 

PUnitFormation 

Enumeration  Type 

unsigned  char 

SUnitFormation 

Enumeration  Type 

unsigned  int 

RelativePosition 

float 

ParkingOffset 

float 

MaxSpeed 

B.2.20  FWA  Sweep 


Table  B.17  Task  ‘FWA  Sweep’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf_point  * 

PointAddr 

float 

Speed 

float 

Altitude 

unsigned  char 

RadarSearchMode 

Enumeration  Type 

unsigned  char 

RadarVolumeAzimuth 

Enumeration  Type 

unsigned  char 

RadarVolumeElevation 

unsigned  char 

RadarVolumeRange 

Enumeration  Type 
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unsigned  char 


unsigned  char 
tf  location  * 
unsigned  int 
unsigned  int 


RadarOrientationLocation 

RadarOrientationAzimuth 

RadarOrientationElevation 


B.2.21  FWA  CAP 


Table  B.  18  Task  ‘FWA  CAP’  data  structure 


Type 

Variable  Name 

Remark 

tfjocation  * 

CAPPosition 

unsigned  int 

CAPOrientation 

float 

LenghOfLegs 

float 

InboundLegSpeed 

float 

OutboundLegSpeed 

float 

CAP  Altitude 

unsigned  char 

RadarSearchMode 

Enumeration  Type 

unsigned  char 

RadarVolumeAzimuth 

Enumeration  Type 

unsigned  char 

RadarVolumeElevation 

Enumeration  Type 

unsigned  char 

RadarVolumeRange 

Enumeration  Type 

unsigned  char 

Enumeration  Type 

unsigned  char 

Enumeration  Type 

tfjocation  * 

RadarOrientationLocation 

unsigned  int 

RadarOrientationAzimuth 

B.122  FWA  CAS  Mission 


Table  B.  19  Task  ‘FWA  CAS  Mission’  data  structure 


Type 

Variable  Name 

Remark 

tf  jocation  * 

ForwardAirController 

unsigned  char 

NumPoints 

RouteToForwardAirController 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

OptionalRetumRoute 

tf  point  * 

PointAddr 

float 

FlightSpeed 

float 

Altitude 

xmsigned  char 

FlightMethod 

Enumeration  Type 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  int 

TimeOnStation 

unsigned  char 

ActionsAfterMission 

t  Emuneration  Type 
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B.2.23  FWA  Ingress 


Table  B.20  Task  ‘FWA  Ingress’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

float 

Speed 

float 

Altitude 

unsigned  char 

Formation 

unsigned  char 

MovementType 

Enumeration  Type 

unsigned  char 

AtEndOflloute 

Enumeration  Type 

B.2.24  FWA  Attack  Ground  Target 

Table  B.21  Task  ‘FWA  Attack  Ground  Target’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumTargets 

tf  point  * 

TargetAddr 

imsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

float 

Speed 

float 

Altitude 

unsigned  char 

MovementType 

Enumeration  Type 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

AttackGeometry 

Enumeration  Type 

unsigned  char 

AttackEntry 

Enumeration  Type 

unsigned  char 

AttackDelivery 

Enumeration  Type 

weaponsenabled  * 

WeaponEnabledAddr 

structure  pointer 

imsigned  char 

MissionType 

Enumeration  Type 

Table  B.22  Task  ‘weaponsenabled’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

Bombs 

boolean 

unsigned  char 

Guns 

boolean 

unsigned  char 

Missiles 

boolean 

B.2.25  FWA  Egress 

same  as  Task  “FWA  Ingress”. 
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B.2.26  FWA  Return  to  Base 


Table  B.23  Task  ‘FWA  Return  to  Base’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

unsigned  char 

NumPoints 

Optional  Return  Route 

tf  _point  * 

PointAddr 

tf  location  * 

TargetLocation 

unsigned  char 

FlightMethod 

Enumeration  Type 

float 

FlightSpeed 

float 

Altitude 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

MissionType 

Enumeration  Type 

unsigned  char 

ActionAfterMission 

Enumeration  Type 

B.2.27  FWA  Interdiction 

Table  B.24  Task  ‘FWA  Interdiction’  data  structure 


-  . Type 

Variable  Name 

Remark 

unsigned  char 

NiunPoints 

RouteToTarget 

tf_point  * 

PointAddr 

unsigned  char 

NumPoints 

OptionalRetumRoute 

tf  point  * 

PointAddr 

tfjocation  * 

TargetLocation 

unsigned  char 

FlightMethod 

Enumeration  Type 

float 

FlightSpeed 

float 

Altitude 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

MissionType 

Enumeration  Type 

unsigned  char 

ActionAfterMission 

Enimieration  Type 

B.2.28  RWA  Fly  Route 

Table  B.25  Task  ‘RWA  Fly  Route’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

Route 

tf  point  * 

PointAddr 

float 

Speed 

float 

CatchUpSpeed 

float 

Altitude 

unsigned  char 

Formation 

Enumeration  Type 

unsigned  char 

Spacing 

Enumeration  Type 

float 

UserDefinedSpacing 

unsigned  char 

MovementType 

Emuneration  Type 
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unsigned  char 

TargetFacingMode 

boolean 

tf  location  * 

NapOfEarthTRP 

B.2.29  RWA  Hover 


Table  B.26  Task  ‘RWA  Hover’  data  structure 


Type 

Variable  Name 

Remark 

tf_  location  * 

FARPPoint 

float 

Speed 

float 

Altitude 

unsigned  char 

ActiveFuelFARP 

boolean 

unsigned  char 

ActiveAmmoFARP 

boolean 

B.2.30  RWA  Orbit 


Table  B.27  Task  ‘RWA  Orbit’  data  structure 


Type 

Variable  Name 

Remark 

tf_location  * 

CenterPoint 

float 

Radius 

float 

Speed 

float 

Altitude 

B.2.31  RWA  Assemble 

same  as  Task  “RWA  Orbit”. 

B,2.32  RWA  Attack 


Table  B.28  Task  ‘RWA  Attack’  data  structure 


Type 

Variable  Name 

Remark 

tf  location  * 

Objective 

float 

Speed 

imsigned  char 

AttackType 

Enumeration  Type 

B.2.33  RWA  Hasty  Occupy  Position 

Table  B.29  Task  ‘RWA  Hasty  Occupy  Position’  data  structure 


Type 

Variable  Name 

Remark 

unsigned  char 

NumPoints 

BattlePosition 

tf  point  * 

PointAddr 

tfjocation  * 

LeftTRP 
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tf  location  * 

RightTRP 

tf  location  * 

EnggAreaTRP 

unsigned  char 

TargetFacingMode 

boolean 

float 

float 

Altitude 

float 

AltitudeAtEnt 

B.3  Enumeration  Type  for  Variables  in  Task 

Task  Kind _ Variable  Names _ Field  Value 


Assault 


Breach 


Change  Formation 


Secure  Objective 

0:No  l:Yes* 

*:  default  value 

Formation 

0  :  Other 

1 :  Column 

2  :  Staggered-Column 

3  :  Echelon-Right 

4  :  Echelon-Left 

5  :  Line* 

6 ;  Wedge 

7:  Vee 

Spacing 

0 :  Other 

1 :  Closed* 

2  :  Open 

3  ;  User  Specifed 

Create  Markers 

0  :  Other 

1  :  Breach  Lanes* 

2  :  No  Markers 

Formation 

Same  as  ‘Assault’-  ’Formation ’ 

*Wedge 

Cross-leveling 


Follow  Simulator 


Supply  to  Cross-level 

0 :  Other 

1  :  Most  unbalanced  non-foel  munition* 

2  :  Fuel 

Travel  Type  0  :  Other 

1  :  Road  March 

2  :  Cross  Country* 

Formation  Same  as  'Assault  ’-  'Formation  ’  *  Wedge 

Spacing  Same  as ‘Assault ’-’Spacing’  *Closed 


FWA  Attack  Ground  Tgt  Movement  Type 


Formation 


0 :  Other 

1  ;  Low  Level 

2  :  Contour* 

0 :  Other 

1  :  Fighting  Wing* 

2  :  Line  Abreast 

3  :  Bearing 
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FWACAP 


Attack-Geometry 

4  :  Trail 

5;  VIC 

6  :  Box 

7 :  Offset  Box 

0 :  Other 

Attack-Entry 

1 :  Direct* 

2 ;  Split 

3  ;  90-10 

4:  Trail 

0  :  Other 

Attack-Delivery 

1 ;  Pop-Up 

2 :  Level* 

3  :  Standoff  AGM  Pop-Up 

4  :  Standoff  AGM  Med  Alt  Dive 
0 :  Other 

Weapons  Enable 

Bombs; 

1  :  Laydown 

2  :  Low  Altitude  Dive* 

3  :  Medium  Altitude  Dive 

4 ;  Strafe 

0:No  l:Yes* 

Guns : 

0:No  l;Yes* 

Missiles : 

0:No  l:Yes* 

Mission  Type 

0  :  Other 

Radar  Search  Mode 

1 :  Targets  are  vehicles* 

2  :  Target  is  a  location 

0 :  Other 

Radar  Volumn  Azimuth 

1  :  Track  While  Scan(Manual)* 

2  :  Track  While  Scan(Auto) 

0  :  Other 

Radar  Volumn  Elevation 

1  :  +/- 10  Degrees 

2  ;  +/-  20  Degrees 

3  :  +/-  40  Degrees* 

4  :  +/-  60  Degrees 

0  :  Other 

Radar  Volumn  Range 

1  :  8Bar 

2:4Bar 

3  : 2  Bar* 

4:  IBar 

0 :  Other 

Radar  Vc  Setting 

1  ;20NM 

2:50NM 

3  ;  100  NM* 

4  :  200  NM 

0  :  Other 

Radar  Orientation  Type 

1  :  +/- 1600  knots* 

2  ;  0-1600  knots 

3  :  0-(-1600)  knots 

0 :  Other 

1  :  Use  Orientation  Az/El  * 

2  :  Use  Orientation  Location 
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FWACAS 


FWA  Sweep 


FWA  Ingress 


FWA  Interdiction 
♦Contour 


Occupy  Position 


Travel 


FlightMethod  Same  as  'FWA  AGT’-  ’Movement  Type  ’  *Contour 
Formation  Same  as ‘FWA  AGT’-’Formation’  *Fighting  Wing 
At  End  of  Route  0  :  Other 

1 :  Oihit* 

2  :  Land 


Radar  Search  Mode  Same  as  ‘FWA  CAP  ’ 
Radar  Volumn  Azimuth  Same  as  ‘FWA  CAP  ’ 
Radar  Volumn  Elevation  Same  as  ‘FWA  CAP  ’ 
Radar  Volumn  Range  Same  as  ‘FWA  CAP  ’ 
Radar  Vc  Setting  Same  as  ‘FWA  CAP ' 

Radar  Orientation  Type  Same  as  ‘FWA  CAP  ’ 


Formation  Same  as ‘FWA  AGT’-’Formation’  *Fighting  Wing 
Movement  Type  Same  as  ‘FWA  AGT ’-’Movement  Type’  *Contour 

At  End  of  Route  0  :  Other 

1  :  Orbit* 

2 :  Land 


FlightMethod  Same  as  ‘FWA  AGT’-  ’Movement  Type  ’ 


Formation  Same  as  ‘FWA  AGT’-  'Formation  ’  *Fighting  Wing 

Mission  Type  Same  as  ‘FWA  AGT’-  ’Mission  Type  ’  *  Attack  fixed 

emplacement 


ActionsAfterMission  0  :  Other 
1 :  Orbit* 
2  :  Land 


Use  Alternative  Position 
Trigger  Criterion 


Trigger  Unit  Size 


Travel  Type 

Formation 

Spacing 


0:No  l.Yes* 

0 :  Other 
1 :  First  Vehicle* 

2  :  Last  Vehicle 

3  :  Unit  Center  of  Mass 
0 :  Other 

1 :  Vehicle 

2  ;  Squad 

3  :  Section 

4 :  Platoon  * 

5  :  Company 

6  ;  Battallion 
7 ;  Regiment 
8 :  Brigade 

9  :  Division 

10  :  Corps 

11  ;  Army 

12  :  Army  Group 


Same  as  ‘Follow  Simulator  ’ 
Same  as  ‘Assault  ’ 

Same  as  ‘Assault  ’ 
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Overwatch  Move 


Use  Concealed  Routes  0;No  l:Yes* 

Movement  0 :  Other 

1 :  Boundary  Overwatch* 

2 ;  Non-Boundary  Overwatch 
3  :  Boundaiy(No  Overwatch) 


Spacing  Same  as ‘Assault’ 

Formation 

0:  Other 

1 ;  Line* 

2 :  Column 

DI  Formation 

0 :  Other 

1 :  Rudel* 

2 ;  Reihe 

Randezvous 

PUnitFormation 

0 :  Other 

1 :  Wedge 

2 ;  Line 

3  :  Vee 

4  :  Coluitm 

\ 

5 ;  Staggered-Column* 
6 :  Echelon-Right 

7 :  Echelon-Left 

SUnitFormation 

0 :  Other 

1 :  Wedge 

2  :  Line 

3  :  Vee 

4 ;  Colunm 

5 :  Staggered-Column* 
6 :  Echelon-Right 

7 :  Echelon-Left 

RWA  Attack 

Attack  Type 

0 :  Other 

1 :  Hover  Attack* 

2  :  Running  Attack 

RWA  Fly  Route 

Fomation 

0 :  Other 

1 :  Wedge* 

2 :  Line 

3  :  Echelon  Right 

4 :  Echelon  Left 

5  ;  Trail 

6 :  Straggered  Right 

7 ;  Straggered  Left 

8  :  Pair  in  trail 

Spacing  Same  as  'Assault’ 

Movement  Type 

0 :  Other 

1  :  Nap  of  Earth 

2  :  Contour* 

3  :  Low  Level 

Target  Facing  Mode 

0;No*  l:Yes 

RWA  Occupy  Position 

Target  Facing  Mode 

0:No*  liYes 

RWA  Unit  FARP 

Active  Fuel  FARP 

0 :  Other 
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Active  Ammo  FARP 


Traveling  Overwatch 


Withdraw 


1  :  Disable  Reaction 

2  :  Enable  Reaction* 
0  :  Other 

1  ;  Disable  Reaction 

2  :  Enable  Reaction* 

Formation  Same  as  ‘Assault’ 

Spacing  Same  as  ‘Assault’ 

Conform  to  Terrain  0:No*  l:Yes 


Smoke  0 :  Other 

1  :  Enabled 

2  :  Disabled* 
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Appendix  C.  Command  Line  Interface  for  SFT 


NAME 

SFT  -  Scenario  File  Translator 
SYNOPSIS 

SFT  [  -help  ]  [  -N|n  ]  [  -C|c]  [  options  ] 

DESCRIPTION 

SFT  converts  a  scenario  to  another  type  of  scenario.  A 
scenario  file  that  will  be  translated  to  another  format 
is  called  'source  scenario',  and  a  scenario  file  which 
is  produced  by  SFT  is  'target  scenario' . 

A  'source  simulation'  is  a  computer  simulation  name 
which  operates  a  source  scenario,  a  'target  simulation' 
is  a  name  of  computer  simulation  which  the  target 
scenario  will  be  run. 


OPTIONS 

The  following  options  are  supported: 
-help 

Show  the  usage  message . 


-N|n 

Show  the  corresponding  numbers  of  each  simulation 


-C|c 

SFT  interactive  with  the  user.  SFT  asks  a  source 
simulation  type,  a  source  scenario  file  name,  a 
target  simulation  type  and  a  target  scenario  file 
name . 

-s  [number]  [input] 

Name  the  source  simulation  name  number  and  source 
scenario  file,  'input'  should  have  a  correct 
directory  path  and  file  name. 

-t  [number]  [output] 

Name  the  target  simulation  name  number  and  target 
scenario  file,  'output'  should  have  a  correct 
directory  path  and  file  name. 


OTHER  NECESSARY  INPUT 

When  converting  a  source  scenario  to  ModSAF  scenario. 
Exercise  ID  and  terrain  file  path/name  are  needed. 

Converting  to  EADSIM  scenario  file,  laydown  file  name 
without  suffix  (.lay)  is  necessary. 
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If  a  source  simulation  is  BATTLESIM,  there  can  be 
several  input  files  to  build  a  scenario.  Be  sure  all 
input  files  are  ended  with  series  of  number  from  0 . 

In  that  case,  input  file  to  SET  is  the  first  file 
name  and  the  number  of  files  is  needed  to  convert  to 
a  target  scenario. 

EXAMPLES 

SET  -s  1  ./data/scn.l  -t  2  ./data/scn.2 

Convert  a  source  scenario  scn.l  of  corresponding 
source  simulation,  which  is  located  in  ./data  to  a 
target  scenario  sen. 2  of  simulation  number  2  into 
./data  directory. 


AUTHOR 

Captain  Heon-Gyu  Park,  Republic  of  Korea,  Army. 
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